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Kedves olvasóink! 

Mint majd az újság átlapozásakor észre 
fogják venni, került e decemberi szám- 
ba egy-két olyan oldal, amely nem 
annyira a szoftverek használatára, mint 
inkább a karácsony utáni ünnepekre, a 
szilveszterre és az újévre , készít fel". A 
Dupla KV mellett ebben a hónapban át- 
menetileg Dupla Pezsgő rovat is van. 
Nem feledve lapunk küldetését, e hónap- 
ban is sok szakmai érdekességről olvashat- 
nak, hisz célunk, hogy a magyarországi IT 
szakemberek ismeretei továbbra is össze- 
mérhetőek legyenek más, fejlettebb orszá- 
gok mérnökeivel. Ennek a feladatnak ellá- 
tására mi magunk kicsik vagyunk, nem véletlen, hogy a Microsoft 
nagy hangsúlyt helyez Hivatalos Oktatóközpontjai (MSCTEC) által 
tartott tanfolyamainak színvonalára. Az utóbbi időben azonban 
úgy látszik, valami nem stimmel ezen a tájon. Nem a Microsoft el- 
kötelezettsége hagyott alább, nem fogytak el, sőt megszaporodtak 
az elsajátítandó ismeretek. .. Akkor mi történt? 

Nem lehet egyértelműen kijelenteni, hogy Magyarország 
ezen piaca alvó piac lenne, de egyértelműen azt sem lehet 
állítani, hogy olajozottan működne a gépezet. Ugyan régen 
túlléptünk a tudathasadásos állapoton, egyre többet beszé- 
lünk arról, hogy milyen lényeges az emberi erőforrás, és an- 
nak fejlesztése egy szervezet, sőt egy egész ország életében. 
Vajon hány olyan cég van, amely örömmel küldi szakembe- 
reit egy-egy tanfolyamra? Vajon mennyi idő kell ahhoz, 
hogy rájöjjenek a cégek: hogyha az a személy, akit delegál- 
nak a tréningre, a tudást nem, esetleg a tréning anyagát 
tudja továbbadni a munkatársainak? A megszerzett tudással 
rögtön dolgozni kezd, hogy kamatoztassa azt. Viszont egy 
lábon természetesen egy cég sem áll meg, vagy csak addig 
a pillanatig, amíg az a bizonyos láb ott tartózkodik. 
Egyértelműen kimutatható, hogy hazai szakembereinknek 
legjobban az éri meg anyagilag, ha itthon képzik magukat. 
Nagy a különbség nyugat és kelet Európa árai között, vi- 
szont az információ, a tanfolyam magja mindenhol 
ugyanaz. Egy tréning színvonalát alapvetően az oktató sze- 
mélyisége határozza meg. Egy jó oktató előadói képessége 
nemcsak az adott anyag mély ismeretén alapszik, a teljes 
tudásbázisra betekintése kell legyen, ismernie kell az új 
trendeket, a várható fejlesztéseket. 

A jó oktatót azonban a honlapokon található információk 
alapján nem könnyű kiszűrni, hiszen nem találhatóak meg 
ott a tanfolyami értékelőlapok eredményei. Még ha ezek az 
adatok elérhetőek is lennének, akkor sem lenne garancia ar- 
ra, hogy mindenkit a saját igényeinek megfelelő oktató fog 
képezni. A tanfolyamon résztvevő saját tanfolyamélménye, 
tapasztalata fogja meghatározni, hogy mely oktatótól tanul 
a leghatékonyabban. Talán nem túlzás azt állítani, hogy a 
rendszeresen tanfolyamot látogató szakemberek ezért le- 
hetnek lépéselőnyben, hiszen ők már tapasztalták, hogy 
mely oktatóktól kapják a tudást a nekik megfelelő színvo- 
nalon, és hatékonysággal. 
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Egyébként a számok tükrében döbbenetesek a különbségek Nyu- 
gat- és Kelet-Európa között az oktatási piacon. Nem áll módom- 
ban összevetni a kelet és nyugati államok társadalmi, gazdasági 
és politikai mutatóit, de egyértelmű különbségeket a számok, a 
tények alapján is felfedezhetünk anélkül, hogy mélyebbre ásnánk. 
Óriási különbség van Nyugat- és Kelet-Európa között, ha az 
oktatóközpontok számát tekintjük. Nyugat-Európában a Mic- 
rosoft tanfolyamok több mint 400 oktatóközpontja működik 
(az élen Németország áll 134 oktatóközponttal, utána szorosan 
az Egyesült Királyság). A népességre vetített oktatóközpont- 
szám több mint duplája a hazainak. Ennek ellenére több cé- 
get találunk, melyek - valószínűleg a nagy kereslet miatt - 
több telephellyel is rendelkeznek az adott ország különböző 
pontjain. Ez térségünkre egyáltalán nem jellemző. A kelet-eu- 
rópai oktatóközpontok összesített száma nem éri el a 150-et 
sem! (A kelet- és közép-európai térség élén Lengyelország áll a 
maga 28 oktatóközpontjával.) 

Tény azis, hogy ha áttekintünk egy kicsit a tengerentúlra, felfedezhet- 
jük, az USA-ban még ennél is rózsásabb a helyzet. Csak New York ál- 
lamban 106 nyilvántartott oktatóközpont működik. Képzelhetjük men- 
nyi lehet az oktatóközpontok száma az USA egész területén! 

Nagy különbségek vannak országonként a tanfolyamok árában 
is. Ugye mondani sem kell, hogy ebben a kategóriában is az 
USA vezet? Itt a tanfolyam költsége átlagosan 431 USD/nap, 
ami egy ötnapos tanfolyam esetén egy magyar tanulni vágyó- 
nak 668.000,-forintjába kerülne, természetesen szállás és úti- 
költségek nélkül! Németországban közel 500.000,- forintért, 
az osztrákoknál 400-500 ezer forintért ülhetnénk be egy öt- 
napos tanfolyamra. Ausztriától és Németországról keletebbre 
azonban az árak mintha laposkúszásban haladnának. Még a 
térségünkben fejlettnek mondható lengyelek sem adják napi 
123 USD-nél drágábban a tanfolyamaikat. Magyarországon a 
tanfolyamok 90 USD körül mozognak naponként. 
Megnyugtatásképpen azért hozzáfűzném, hogy ezek a szá- 
mok nem mutatják az oktatás minőségének színvonalát. 
Nem jelenti, hogy a mi tanfolyamaink nem elég jók. Az bi- 
zonyos, hogy az oktatás kínálatában nem vagyunk elmarad- 
va. Európa minden része tartja a lépést a Microsoft iramával. 
A curriculumban felsorolt közel 140 tanfolyam felöleli a tel- 
jes kínálatot a Windows NT 4.0-tól a Windows 2000-ig, az 
Exchange 2000-től az SOL tanfolyamokig. A fenti listából vá- 
laszthatják ki az oktatóközpontok az erőforrásuknak és pro- 
filuknak megfelelő kínálatukat. Dicséretes, hogy a magyaror- 
szági oktatóközpontok is képesek megújulni, hiszen az inno- 
váció, a folyamatos lépéstartás, az erőforrások fejlesztése 
ezekben a cégekben éppúgy zajlik, mint nyugaton. 

Tehát leszögezhetjük, hogy nincs baj a tanfolyami árakkal, 
ha csak az nem, hogy túl alacsonyak. Nincs baj a kínált tan- 
folyamok változatosságával és az oktatás minőségével sem. 
Nincs túl sok oktatóközpont sem a magyar piacon. 

Csak nem az a baj, hogy nem akarunk tanulni!? 


Kovács Barbara 
Training manager 
kovacs.barbara (onetacademia.net 
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Small Business Server 2000 
A .NET kiszolgálócsalád debütálása után már 
szinte készen van a kisvállalatoknak szánt cso- 
mag, a Small Business Server 2000 is. A 
http://www.microsoft.com 

sbserver/productinfo/SBS2000.htm . címen 
már most olvashatunk a termék újdonságairól, 
ami a hírek szerint 2000 vége helyett csak a jö- 
vő év elején fog megjelenni, és a Windows 2000 
mellett szinte a teljes .NET palettát (Exchange 2000, 
SOL Server 2000, ISA Ser- 
ver) felvonultatja majd. A 
Windows 2000 Magazine ér- 
tesülései szerint az SBS2K- 
ban addigra már a Service 
Pack 2-vel ellátott Windows 

2000-et találunk. 
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Javítócsomagok a láthatáron 

Ha már a javítócsomagoknál tartunk: megjelent az Internet 
Explorer 5.5 SP1 és az Office 2000 Service Pack 2. Mindkét 
javítócsomag elsősorban biztonsági javításokat tartalmaz. 
Az Office 2000 Service Pack 2 két változatban tölthető le: 
a kilenc megabájtos változat az otthoni felhasználók szá- 
mára, a harminc megabájtos példány pedig vállalati környe- 
zetbe, központi telepítéshez szükséges. A http://www.mi- 
crosoft.com/windows/ie illetve http://www.microsoft.- 
com/offi. rk/2000/journ, P2.htm címről letölthe- 
tő csomagok angol nyelvhez készültek, de mindkettőből 
várható a magyar nyelvű változat is. 


Letölthető a Visual Studio.NET és a Whistler 
Beta 1 

A http://msdn.microsoft.com/vstudio/next- 
gen/beta.asp címről az MSDN előfizetők már 
letölthetik a Microsoft új generációs fejlesztő- 
készletének első nyilvános béta változatát. 
Ugyancsak itt érhetik el az MSDN Professional és MSDN Uni- 
versal csomag tulajdonosai a Whistler első nyilvános bétáját 
is. Szintén ehhez a hírhez tartozik, hogy a Microsoft az új Ct 
programozási nyelvet és a .NET keretrendszer egy részét fel- 
terjesztette szabványosításra az ECMA (European Computer 
Manufacturers Association) szervezethez. Ugyanez a szerve- 
zet végezte a JavaScript (nem a Java) szabványosítását is. 


ál, 
net 


beta 1 


A Microsoft bejelentette a FrontPage 10-et 

A FrontPage webszerkesztő-eszköz új változata hű marad a 
fejlesztések irányához: az új változat többek között fejlet- 
tebb képkezelést, gazdagabb galériákat, automatikus webes 
eszközöket (MSN keresőt, Expedia térképet), rendszerfelü- 
gyeleti összetevőket (használati analízis, toplisták) és tel- 
jes csoportmunka-támogatást tartalmaz majd. A FrontPage 
10 jelenleg Beta 2 állapotban tart, és az Office 10-zel kar- 
öltve valószínűleg jövő év közepén jelenik majd meg. Az új 
FrontPage szolgáltatásairól addig is a http://www.micro- 
soft.com/presspass/features/2000/novOO/11-28front- 
page.asp címen olvashatunk. 
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Itt a DirectX 8! 
Megjelent a Microsoft multimédia-könyvtárának legújabb 
változata, a DirectX 8 is. A DirectX 8 az új hardverek támo- 
gatása mellett 
fotóminőségű  3D 
animációt, fejlet- 
tebb hálózati játék- 
támogatást és 3D 
hangkezelést bizto- 
sít. A teljes fejlesz- 
tői változat, a Di- 
rectX 8 SDK a 
http: n.mi 
crosoft. TönZálTÉzE címről kiindulva tölthető le, mindegy 
145 megabájtot kóstál. A felhasználók megússzák keveseb- 
bel: a Windows 95/98/ME változat 11, a Windows 2000-re 
készült verzió pedig 8 megabájt. A felhasználói letöltéseket 
a http://www.microsoft.com/directx címről lehet elérni. 
A bővítés egyelőre ma- 
gyar nyelven nem ér- 











hető el, de az oldalon b 
már most is számos 

nyelvi verzió található, 

így joggal várhatjuk a n 

magyar változat meg- 

jelenését is. (A tapasz- É 

talat azt mutatja, hogy 

az eddigi verziók eseté- A 

ben nem okozott külö- 

nösebb gondot, ha magyar nyelvű operációs rendszerre angol 
nyelvű DirectX-et telepítettünk. Ha van kedvünk kockáztatni, 
talán érdemes megpróbálni.) 

Mi az a TabletPC? 

A COMDEX alkalmával, 
Las Vegasban mutatta be 
Bill Gates a TransMeta 
(http: // www.transme- 
ta.com) Crusoe mobil 
processzorára — alapuló, 
Windows-t futtató Tab- 
letPC prototípusát. A gé- 
pen már a bemutatón 
Whistler futott, és min- 
den bizonnyal ez az igazi 
várományosa az új plat- 
formnak. ,A TabletPC egyesíti a számítógép a papír és ceruza 
előnyeit" - mondja a szlogen. A 
felhasználóinak nem kell komp- 
romisszumokat kötni: ez egy 
teljesértékű számítógép. Az első 
TabletPC megjelenése 2002 vé- 
gére, talán 2003-ra várható. 





Bert Keely rendszermérnök 
és a TabletPC prototípusa 
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Microsoft Certified Partner 
program 

Mint azt már novemberi számunk- 
ban is említettük, januártól meg- 
újul a Microsoft partneri program- 
ja (a volt MCSP program). A Micro- 
soft Certified Partner program két 
MCP minősítésű, a Microsoft Gold 
Certified Partner pedig specializálódástól függően (elektro- 
nikus kereskedelem, vállalati rendszerek, Internet- és alkal- 
mazás-szolgáltatók, ügyféltámogatás) 4-7 MCSE rendszer- 
mérnök munkatárs bejegyzését és természetesen az éves 
díj befizetését tűzi feltételként a belépéshez. A regisztrá- 
ció máris megkezdődött, a partneri program további rész- 
leteiről a Microsoft Magyarország weboldalán, a 
http://www.microsoft.com/hun/partner/ 
certpartner.htm címen tájékozódhatunk. 


— Adöstra KR 
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Elkészült a Microsoft Szerviz 
CD7 

Megjelent a Microsoft Magyar- 
ország negyedévi rendsze- 
rességgel — kiadásra kerülő 
szervízcsomag-sorozatának 7. 
tagja. A dupla CD-n a Microsoft 
Tudásbázis anyagai mellett 
megtalálhatók az általánosan használt Microsoft operációs 
rendszerek és irodai alkalmazások legfrissebb javítócso- 
magjai, valamint egyik legnépszerűbb játékának, az Age Of 
Kings-nek demo változata is. A csomag egy példányban 
ingyenesen rendelhető a Microsoft Ügyfélszolgálattól, a 
további példányok ára 1000 Ft. 








Teljes és átfogó lel- 
tárt kérek az informa- 
tikai eszközeinkről! 


Teljes? Átfo- 
gó? Dehát az 
alkatrészeket 
összevissza 
cserélgettük! 


Helyreigazítás 

Novemberi számunk 31. oldalán, az NTLMv2-t tárgyaló 
cikkünkbe sajnálatos hiba csúszott. A hiba a Windows 9x 
registry kulcsának nevében volt, pontosan az az informá- 
ció maradt ki a cikkből, amiért az tulajdonképpen író- 
dott. A lényeg az, hogy a Windows 9x regisztrációs 
adatbázisában található, az NTLMv2-t engedélyező érték 
neve LMCompatibilityLevel helyett helyesen: LMCompatibility. 
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Miért? Melyik betűt 
nem ismered? 


A telepítés után a Windows9x kompatibilitási okok miatt 
még az eredeti LM azonosítást használja, de a következő 
registry értékek módosításával le lehet erről beszélni: 


HKLMNSystemlCurrentControlSetlcontrolNlLSA 
Value Name: LMCompatibility 
REG DWORD 


Data Type: 
Value: 3 
,Valid Range: 0-3 
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WINDOWS 2000 


Domain Naming System 2.rész. 


A DNS ügyfelek beállítása 

A Windows 2000 DNS ügyféloldalán általában 
kevés beállítani valónk akad, ami az esetek 
többségében kimerül egy elsődleges (és eset- 
leg egy másodlagos) DNS kiszolgáló IP címé- 
nek megadásában. Szerencsére ezt a felada- 

tot is rábízhatjuk a DHCP kiszolgálóra. 
Az ügyféloldali alapbeállítások rendszerint meg- 
felelők, de előfordulhatnak olyan helyzetek, ame- 
lyekben ezeket célszerű megváltoztatni. Az alábbi 
rendszerleíró azonosítók ebben lesznek majd segítségünkre. 


Az alapértelmezett TTL beállítása 

A DNS ügyfelek az A és PTR rekordok TTL-jét alaphelyzetben 
20 percre állítják be, amit megváltoztathatunk a következő 
rendszerleíró azonosítóval: 


DefaultRegistrationTTL 

Az azonosító helye: 

HKEY LOCAL MACHINENSYSTEMÍCurrentControlsSetV 
ServicesíTcpiplParameters 

Adattípus: REG DWORD (másodpercben) 

Alapértelmezett érték: ox4Bo (decimális értéke 1200 má- 
sodpercnek, vagyis 20 percnek felel meg) 

Értelmezési tartomány: 0—OxFFFFFFFF 
(Alapértelmezésben nem létező azonosító) 


A dinamikus frissítés kikapcsolása 

Az automatikus frissítés látszólag egyértelmű hasznossága 
ellenére néha nemkívánatos is lehet. A következő rendszer- 
leíró azonosítóval a dinamikus frissítés akár a teljes számí- 
tógépre, akár egyetlen kártyára is kiiktatható: 


DisableDynamicUpdate 

Az azonosító helye: 

KEY LOCAL MACHINENSYSTEM(CurrentControlsSett 
Services TcpiplParameters 

vagy 

HKEY LOCAL MACHINENSYSTEMÍCurrentControlsett 
Services TcpipNParametersWnterfaces) 
Sinterfaces 

Adattípus: REG DWORD (logikai) 

Értelmezési tartomány: o (hamis), 1 (igaz) 
Alapértelmezett érték: o (hamis: dinamikus frissítés enge- 
délyezve) 

(Alapértelmezésben nem létező azonosító) 


Lekérdezés 

Az ügyfélprogram egy tartománynevet tartalmazó lekérde- 
zést küld a DNS kiszolgálónak, amelynek hatására az a ne- 
vet megpróbálja megtalálni és a hozzá tartozó erőforrásre- 
kordokat visszaküldeni. A lekérdezésben a keresett tarto- 
mány nevén kívül a visszaküldendő rekordtípusok kódja is 
megtalálható. 

Az alábbi Network Monitor (NM) napló bemutatja egy tar- 
tománynév lekérdezését. (A sors akarta így, hogy bemelegí- 
tő NetMon cikkem mellé mindjárt itt egy durva trace. Mea cul- 
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pa, forró ólmot a fülembe. Mentségemre legyen mondva, 
hogy a cikk hátralévő részében azért mezőnként és bitenként 
felsorolom mindazt, ami itt jön.) 


Kérdés: 
1 4.866998 LOCAL 3COM 884403 DNS 0x1587: 
Std Ory for masina.falatrax.hu. of type Host 
DNS 10.10.2.200 
4 Frame: Base frame properties 
4 ETHERNET: ETYPE -— 0x0800 : Protocol — IP: 
Internet Protocol 
4 IP: ID - OXEEA8; Proto - 
4 UDP: Src Port: Unknown, 
(53); Length -— 41 (0x29) 
DNS: 0x1587:Std Ory for masina.falatrax.hu. of 
type Host Addr on class INET addr. 
DNS: Ouery Identifier -— 5511 (0x1587) 
4 DNS: DNS Flags — Ouery, OpCode - Std Ory, 
RD Bits Set, RCode - No error 
DNS: Ouestion Entry Count — 1 (0x1) 
DNS: Answer Entry Count -— 0 (0x0) 
DNS: Name Server Count — 0 (0x0) 
Additional Records Count — 


DOD 


UDP; Len: 61 
(4715); Dst Port: DNS 


DNS: 
0 (0x0) 

DNS: Ouestion Section: masina.falatrax.hu. 
of type Host Addr on class INET addr. 


DNS: Ouestion Name: masina.falatrax.hu. 
DNS: Ouestion Type - Host Address 
DNS: Ouestion Class - Internet address 
class 
Válasz: 


2 4.866998 3COM 884403 LOCAL DNS 0x1587: 
Std Ory Resp. for masina.falatrax.hu. of 
type 

10.10.2.200 DNS IP 

4 Frame: Base frame properties 

4 ETHERNET: ETYPE - 0x0800 : Protocol -— 
DOD Internet Protocol 

4 IP: ID — OxX7BAA; Proto - UDP; Len: 77 
4 UDP: Src Port: DNS, (53); Dst Port: 
Unknown (4715); Length — 57 (0x39) 

DNS: 0x1587:Std Ory Resp. for masina.fa- 
latrax.hu. of type Host Addr on class INET 
addr. 

DNS: Ouery Identifier — 5511 (0x1587) 

4 DNS: DNS Flags — Response, OpCode - 

Std Ory, AA RD RA Bits Set, RCode - No 
error 

DNS: 

DNS: 

DNS: 

DNS: 
0 (0x0) 

DNS: Ouestion Section: masina.falat- 
rax.hu. of type Host Addr on class INET 
addr. 


IP: 


Ouestion Entry Count — 1 (0x1) 
Answer Entry Count — 1 (0x1) 
Name Server Count — 0 (0x0) 
Additional Records Count -— 
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DNS: Ouestion Name: 
masina. falatrax.hu. 

DNS: Ouestion Type -— Host Address 

DNS: Ouestion Class — Internet 
address class 

DNS: Answer section: masina.falat- 

rax.hu. of type Host Addr on class INET 
addr. 

DNS: Resource Name: masina.falat- 
rax.hu. 

DNS: Resource Type - Host Address 

DNS: Resource Class — Internet 


DNS: Time To Live -— 1200 (0Ox4B0O) 

DNS: Resource Data Length — 4 
(0x4) 

DNS: IP address -— 10.10.2.200 


A fenti ,párbeszédben" egy ügyfél DNS lekérdezést küld a 
DNS kiszolgálónak, amelyre a masina.falatrax.hu-hoz tar- 
tozó összes A rekordot várja válaszként. A válaszban a kért 
rekord(ok) mellett megtaláljuk a kérdést is. Példánk tarto- 
mánynevéhez csak egy A rekord tartozik, amely a 
10.10.2.200 címre mutat. A fordított lekérdezés lefolyása 
nagyon hasonló, ezért erre nem mutatunk be példát. 


Aliasok lekérdezése 

A kérdező nem tudhatja előre, hogy a felhasználó által 
megadott tartománynév A vagy CNAME rekordra vonatko- 
zik, ezért a CNAME átalakítását is el kell végezni. A járulé- 
kos hálózati forgalom csökkentése érdekében a DNS kiszol- 
gáló a CNAME rekorddal együtt az összes hozzárendelt A 
rekordot is beleteszi a válaszba. 

Az alábbi NM napló bemutatja egy alias lekérdezését: 


Kérdés: 
1 6.559432 DNS Server DNS 
client DNS 0x1590:Std Ory for 


ns1.falatrax.hu. of type Host A DNS 
10.10.2.200 
4 Frame: Base frame properties 
4 ETHERNET: ETYPE — .0x0O800 : Protocol — IP: 
DOD Internet Protocol 
4 IP: ID — OxXEFCD; Proto - UDP; Len: 60 
4 UDP: Src Port: Unknown, (4761); Dst Port: 
DNS (53); Length -— 40 (0x28) 
DNS: 0Ox1590:Std Ory for nsl.falatrax.hu. 
of type Host Addr on class INET addr. 
DNS: Ouery Identifier — 5520 (0x1590) 
4 DNS: DNS Flags — Ouery, OpCode - Std 
Ory, RD Bits Set, RCode - No error 
DNS: Ouestion Entry Count — 1 (0x1l) 
DNS: Answer Entry Count — 0 (0x0) 
DNS: Name Server Count — 0 (0x0) 
DNS: Additional Records Count -— 0 


DNS: Ouestion Section: nsl.falatrax.- 


WINDOWS 2000 / DOMAIN NAMING SYSTEM 


hu. of type Host Addr on class INET addr. 
DNS: Ouestion Name: nsl.falatrax.- 

hu. 

DNS: Ouestion Type — Host Address 

DNS: Ouestion Class -— Internet 

address class 


Válasz: 

r 6.569446 DNS Client DNS 
Server DNS 0x1590:Std Ory 
Resp. for ú 
nsl.falatrax.hu. of type 10.10.2.200 
IP 


4 Frame: Base frame properties 

4 ETHERNET: ETYPE — 0x0800 : Protocol — IP: 
DOD Internet Protocol 

4 IP: ID — 0x807B; Proto - UDP; Len: 95 

4 UDP: Src Port: DNS, (53); Dst Port: Unk- 
nown (4761); Length — 75 (0Ox4B) 

DNS: 0x1590:Std Ory Resp. for ns1.falat- 
rax.hu. of type Canonical name on class 
INET addr. 

DNS: Ouery Identifier -— 5520 (0x1590) 

4 DNS: DNS Flags — Response, OpCode - 

Std Ory, AA RD RA Bits Set, RCode - No er- 
ror 

DNS: Ouestion Entry Count — 1 (0x1) 
Answer Entry Count — 2 (0x2) 

DNS: Name Server Count — 0 (0x0) 

DNS: Additional Records Count -— 0 

(0x0) 

DNS: Ouestion Section: nsl1.falatrax.- 
hu. of type Host Addr on class INET addr. 
DNS: Ouestion Name: nsl.falatrax.- 


hu. 
DNS: Ouestion Type -— Host Address 
DNS: Ouestion Class — Internet 
address class 
DNS: Answer section: nsl.falatrax.hu. 
of type Canonical name on class INET 
addr. (2 
records present) 
4 DNS: Resource Record: nsl.falatrax.hu. of 
type Canonical name on class INET addr. 
4 DNS: Resource Record: masina.falatrax.hu. 
of type Host Addr on class INET addr. 


A példában a DNS ügyfél lekérdezést küld a DNS kiszolgá- 
lónak, melyben arra kéri, hogy küldje el neki az ns1.falat- 
rax.hu névhez tartozó A rekordot. A név jelen esetben a 
masina. falatrax.hu aliasa, így a válaszban két rekord sze- 
repel: az egyik az ns1.falatrax.hu CNAME rekordja, amely 
az aliast tartalmazza, a másik a masina. falatrax.hu A re- 
kordja, amely megadja a hozzárendelt IP címet. 
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A DNS dinamikus frissítése 

Az RFC 2136 definiálja a DNS zónák dinamikus frissítését. 
A DNS ügyfelek ezzel a zónákba maguk jegyezhetnek be 
vagy törölhetnek erőforrásrekordokat, illetve rekordcsopor- 
tokat. A frissítési kérelmek teljesítése bizonyos feltételek- 
hez köthető, amelyek a frissítési művelettől függetlenül 
határozhatók meg. A végrehajtáshoz az összes előfeltétel- 
nek teljesülnie kell. A Windows 2000 TCP/IP ügyfél és a 
DHCP kiszolgáló dinamikus frissítési kérelmekkel jegyezte- 
ti be az A és PTR rekordokat. A következő NM napló egy A 
rekord dinamikus bejegyzésének folyamatát mutatja be. 





Kérés: 
1 6.270000 DNS Client DNS Ser- 
ver DNS 0x61:Dyn Upd PRE/UPD 


records to CSODAGEP.falatrax.hu 10.10.1.52 
195.152.236.200 
4 Frame: Base frame properties 


4 ETHERNET: ETYPE — 0x0800 : Protocol - IP: DOD 
Internet Protocol 

4 IP: ID — Ox1082; Proto - UDP; Len: 115 

4 UDP: Src Port: Unknown, (3276); Dst Port: DNS 


(53); Length — 95 (Ox5F) 
DNS: 0x61:Dyn Upd PRE/UPD records to CSODAGEP.- 
falatrax.hu. of type Canonical name 

DNS: Ouery Identifier - 97 (0x61) 


4 DNS: DNS Flags - Ouery, OpCode - Dyn Upd, 
RCode - No error 
DNS: Zone Count — 1 (0x1) 
DNS: Prereguisite Section Entry Count - 2 
(0x2) 
DNS: Update Section Entry Count -— 1 (0x1l) 
DNS: Additional Records Count — 0 (0x0) 
4 DNS: Update Zone: falatrax.hu. of type SOA 


on class INET addr. 
4 DNS: Prereguisite: CSODAGEP.falatrax.hu. of 
type Canonical name on class Unknown 
Class(2 records present) 
DNS: Update: CSODAGEP.falatrax.hu. of type 
Host Addr on class INET addr. 


DNS: Resource Name: CSODAGEP.falatrax.- 
hu. 

DNS: Resource Type - Host Address 

DNS: Resource Class -— Internet address 
class 

DNS: Time To Live -— 1200 (0x4BO) 

DNS: Resource Data Length — 4 (0x4) 

DNS: IP address -— 10.10.1.52 
Válasz: 
2 6.270000 DNS Server DNS 
Client DNS 0x61:Dyn Upd Resp. 


PRE/UPD records to CSODAGEP.ka 195.152.236.200 
10.10.1.52 

4 Frame: Base frame properties 

4 ETHERNET: ETYPE - 0x0800 : Protocol — IP: 
Internet Protocol 


DOD 
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4 IP: 
4 UDP: 


115 

(53); Dst Port: Unknown 
(3276); Length — 95 (Ox5F) 

DNS: 0x61:Dyn Upd Resp. PRE/UPD records to CSO- 
DAGEP.falatrax.hu. of type Canonical name 


ID -— Ox86BD; 
Src Port: 


Proto - UDP; Len: 
DNS, 


DNS: Ouery Identifier — 97 (0x61) 
4 DNS: DNS Flags — Response, OpCode - Dyn 
Upd, RCode - No error 
DNS: Zone Count — 1 (0x1) 
DNS: Prereguisite Section Entry Count — 2 


(0x2) 
DNS: Update Section Entry Count - 1 (0xl) 
DNS: Additional Records Count — 0 (0x0) 
4 DNS: Update Zone: falatrax.hu. of type SOA 


on class INET addr. 
4 DNS: Prereguisite: CSODAGEP.falatrax.hu. of 
type Canonical name on class Unknown 
Class(2 records present) 
DNS: Update: CSODAGEP.falatrax.hu. of type 
Host Addr on class INET addr. 
DNS: Resource Name: CSODAGEP.falatrax.- 


hu. 
DNS: Resource Type - Host Address 
DNS: Resource Class — Internet address 
class 
DNS: Time To Live — 1200 (0x4BO) 
DNS: Resource Data Length — 4 (0x4) 
DNS: IP address -— 10.10.1.52 


A példában a DNS ügyfél egy dinamikus kérelmet küld a 
DNS kiszolgálónak a csodagep.falatrax.hu-hoz tartozó A 
rekord frissítésére, melynek IP címe jelenleg 10.10.1.52. 


Zónaátvitel 

A zónaátvitel háromféleképpen valósulhat meg: 

"8 A hagyományos zónaátvitel során a másodlagos kiszol- 
gáló teljes zónamásolatot kér az elsődlegestől. Leírása 
az RFC 1034-ben olvasható. Kész sávszélesség-pazar- 
lás, ha a változás kicsi a teljes zónához képest. 

"8 Az RFC 1995-ben definiált növekményes zónaátvitelhez 
az elsődleges zónát tároló DNS kiszolgálónak emlékez- 
nie kell a zónasorszám növekedései között bekövetke- 
ző változásokra. A másodlagos kiszolgálónak így elég a 
legutóbbi frissítés óta történt változásokat kérnie. 

t Az AD zónaátvitel AD replikációval valósul meg, mely- 
ben az AD zónákat az összes tartományvezérlő megkapja. 

Íme egy NM napló, amely bemutatja a falatrax.hu zóna át- 

vitelét az elsődleges kiszolgálóról a másodlagosra: 


1 60.1765 Secondary Primary TCP ....S., len: 0, 
seg:3436924871-3436924871, ack 
2 60.1765 Primary Secondary TCP 
seg:2396712099-2396712099, ack 
3 60.1765 Secondary Primary TCP 
seg: 3436924872-3436924872, ack 
4 60.1765 Secondary Primary DNS 0OxO:Std Ory for 
falatrax.hu. of type Reg for zn Xfer on 


:A..S., len: 0, 


sA...., len: 0, 
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class INET addr. 

5 60.1865 Primary Secondary DNS OxO:Std Ory 
Resp. falatrax.hu. of type SOA on class 
INET addr. 

6 60.1865 Primary Secondary DNS 0x636F:Rsrvd 
- of type Unknown Type on class 

7 60.1865 Secondary Primary TCP .A...., len: O, 
seg: 3436924904-3436924904, ack 

8 60.2366 Secondary Primary TCP .A...F, len: O, 
seg:3436924904-3436924904, ack 

9 60.2366 Primary Secondary TCP .A...., len: O, 
seg:2396714217-2396714217, ack 

10 60.2366 Primary Secondary TCP .A...F, len: O, 
seg:2396714217-2396714217, ack 


for 


for 


Példánkban a másodlagos DNS kiszolgáló először felépít 
egy TCP kapcsolatot az elsődleges kiszolgálóval, majd zó- 
naátvitelt kér. Az elsődleges zóna DNS kiszolgálója erre a 
zóna erőforrásrekordjainak átküldésével válaszol. A zóna- 
átvitel első és utolsó eleme a SOA rekord. A folyamat vé- 
gén a TCP kapcsolat megszűnik. 

A nagy és/vagy dinamikus zónák növekményes átvitele ha- 
tékonyabb a hagyományosnál. Ez azonban járulékos munká- 
val terheli a DNS kiszolgálót: jegyeznie kell a változásokat, 
és csak a módosított rekordokat kell átküldenie. A standard 
zónák alaphelyzetben ezt az átvitelt használják, ha lehet. 
A következő NM naplóban a falatrax.hu zóna növekményes 
átvitelét követhetjük nyomon: 


1 563.890835 — LOCAL 3COM 6B15C7 
DNS 0x6000:Std Ory for falatrax.hu. of 
type SOA on class INET addr. 

2 563.890835 3COM 6B15C7 
DNS 0x6000:Std Ory Resp. for 
falatrax.hu. of type SOA on class INET addr. 
3 563.890835 — LOCAL 3COM 6B15C7 
DNS 0x4000:Std Ory for falatrax.hu. of 
type Reg for incrmntl zn Xfer on class INET 
addr. 

4 563.890835 3COM 6B15C7 
DNS 0x4000:Std Ory Resp. for 
falatrax.hu. of type SOA on class INET addr. 


LOCAL 


LOCAL 


A fenti párbeszédet kezdeményező DNS kiszolgáló először 
lekéri a SOA rekordot, majd egy növekményes zónaátvitelt 
kér. A negyedik csomagban található válasz egyetlen UDP 
adatrészben elfér. Más lett volna a helyzet akkor, ha a vá- 
lasz csonkolva érkezik, ekkor ugyanis a kezdeményező ki- 
szolgáló TCP kapcsolatot épített volna fel, és ezen keresz- 
tül kérte volna a zónaátvitelt. 

Az AD replikáció csak Windows 2000 tartományvezérlőkkel 
használható. A standard és növekményes zónaátvitel a má- 
sodlagos zónát tároló kiszolgálókra épít, amelyek az elsőd- 
leges zóna változásait letöltik (pull). Az AD replikáció ez- 
zel szemben , push" jellegű. Az AD replikáció a keveset vál- 
tozó zónáknál biztosítja, hogy a zónát tároló DNS kiszol- 
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gálók gyorsan frissülnek, míg a dinamikusabb zónáknál 
egyenletesebbé teszi a replikációs forgalmat. 


DNS erőforrásrekordok 

Mik az erőforrásrekordok? 

Az erőforrásrekord egy DNS tartományról hordoz informá- 

ciót: a címrekord például meghatározza egy munkaállomás 

IP címét. Vannak azonban minden rekordban megtalálható 

adatok is: 

"8 A tulajdonos jelzi, hogy a rekord melyik DNS tarto- 
mányban található. 

"b ATTL azt határozza meg, hogy mennyi ideig kell a re- 
kordot más DNS kiszolgálóknak a gyorsítótárukban tar- 
tani. Ez a mező a legtöbb rekordnál nem kötelező. A 
TTL mértékegysége a másodperc, és a 0 érték azt jelen- 
ti, hogy a rekordot nem kell ideiglenesen tárolni. A 
SOA rekordok alapértelmezett TTL-je például 1 óra, ami 
megakadályozza a rekord hosszú időre történő gyorsí- 
tótárazását, következésképpen a változások késlelte- 
tett terjedését. 

"0 A rekordok osztályokba sorolhatók, amelyeket mnmemoni- 
kokkal jelölünk. Az IN például azt jelzi, hogy a rekord 
az Internet osztályhoz tartozik. Korábban több osztály 
is létezett (például CH - Chaos Net), de jelenleg csak 
az IN-t használjuk. 
A rekord típusát feltüntető mnemonik használata köte- 
lező. Az A mnemonik például címrekordot jelöl. 
Az erőforrás további leírása adható meg a változó 
hosszúságú rekord specifikus adatmezőben, melynek 
formátuma a rekord típusától és osztályától függ. 
A Windows 2000 DNS kiszolgálóknál az összes DNS adat au- 
tomatikusan létrejön vagy meghagyható az alapértelme- 
zett beállítása. Az erőforrásrekordok részletes ismerete el- 
sősorban azoknak lehet hasznos, akik a Windows 2000 más 
rendszerekkel való integrálására, illetve hibajavításra kí- 
vánják használni. 

A standard DNS zónafájlok egyszerű szövegfájlok. Minden 

erőforrásrekord külön sorban található, és az összes fenti 

adatot is tartalmazza, egymástól szóközzel elválasztott 

szövegmezők formájában. A zónafájl minden rekordja a 

fent említetett adatokból áll, egyedül a rekord specifikus 

adatmező formátuma lehet eltérő a rekordok típusának és 
osztályának megfelelően. 


Így néz ki egy zónafájl 
A korábban már felvázolt falatrax.hu zóna adatai a követ- 
kezőképpen festenek: 


; Database file falatrax.hu.dns for falatrax.hu 

zone. 

; Zone version: 22508 

; 

é€ IN SOA masina.falatrax.hu. 

latrax.hu. ( 
22508 


900 


administrator . fa- 


; serial number 


; refresh 
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600 ; retry 
86400 :; expire 
3600 ) ; minimum TIL 


ij; Zone NS records 
There are two DNS servers holding this domain 


; 

e NS masina.falatrax.hu. 

e NS csodagep. falatrax.hu. 

; 

i Zone records for Falatrax.hu 

; 

e 600 A 10.10.1.52 

e 600 A 10.10.2.200 

e 600 A 10.10.2.211 

hulla 900 A 10.10.2.211 

csodagep A 10.10.1.52 

masina A 10.10.2.200 

DNS 1200 A 10.10.1.100 
1200 A 10.10.2.100 


; 


ij;  Delegated sub-zone: jh.falatrax.hu. 


; 
jh 
; End delegation 


NS csodagep. falatrax.hu. 


Hol találhatók az erőforrásrekordok? 
A standard zónák rekordjai a zónák nevét és a .dns kiter- 
jesztést viselő fájlokban (például falatrax.hu.dns) találha- 
tók a Wwinnttystem32Ndns mappában. 


Az Active Directoryval integrált zónák erőforrásrekordjai 
Az AD-vel integrált zónák adatai AD objektumokban táro- 
lódnak, amelyek két fő osztályba sorolhatók: 

"0 A dnsZone osztály olyan AD zónákat reprezentál, ame- 
lyek dnsNode objektumokat tartalmaznak. Ez az osztály 
a szövegfájlban tárolt standard zónák megfelelője az 
AD-ben. A dnsZone objektumoknak van egy dnsProperty 
attribútuma, amely a zóna fontos jellemzőit határozza 
meg - például, hogy dinamikusan frissíthető-e? 

A dnsNode osztály a zóna egyes rekordjaira vonatkozik. 
Minden dnsNode objektumnak van egy dnsRecord attribú- 
tuma, amely az erőforrásra vonatkozó adatokat tárolja. 
Az AD-vel integrált zónák tárolási helyét a Windows 2000 
Support Toolsban megtalálható ADSI Edittel tekinthetjük 
meg. Felettébb érdekes, hogy a zóna a tartományi adatok kö- 
zött tárolódik, és nem a Configuration részben. Vajon miért? 
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A Windows 2000-ben támogatott erőforrásrekordok 


A Windows 2000 az összes, RFC-ben definiált rekordtípust 
támogatja, bár ezek jórészét csak ritkán vagy sosem hasz- 
náljuk. Az alábbiakban ismertetjük a leggyakoribb rekordo- 
kat. A típust (a név mellett zárójelben) és a szintaxist is 
feltüntető leírásokat példa is kíséri. 

DNS tartománynevet 32 bites IPv4 címhez kapcsol. 
szintaxis: tulajdonos A IPv4 cím 

példa: csodagep A 10.10.2.200 

DNS tartománynevet 128 bites IPv6 címhez kapcsol. 
szintaxis: tulajdonos AAAA IPv6 cím 

példa: ipvőhost AAAA 4321:0:1:2:3:4:567:89a:b 

A tulajdonos mezőben álló aliast rendel egy másik alia- 
shoz vagy egy valódi tartománynévhez. Ehhez a rekord- 
hoz egy A rekordnak is tartoznia kell, amely a DNS tarto- 
mánynévtér egy érvényes csomópontját adja vissza. A tel- 
jes alias ponttal (,,.") végződik. 

szintaxis: alias CNAME kanonikus név 

példa: ns1 CNAME masina. falatrax.hu 

A zóna önleírója. Tartalmazza a zóna sorozatszámát, ami 
a replikációhoz kell, a replikáció gyakoriságát (refresh), 
hiba esetén mennyi időnként próbálkozzon a secondary 
(retry), s ha végképp nem tudja felvenni a kapcsolatot a 
primaryval, akkor mennyi idő múlva állítsa le a zónát, 
mert a rekordok frissessége több, mint kétséges (expire). 
Apropó, expire. Egyik kedves olvasónk a múltkori, első 
rész után kérte, hogy majd említsem meg a SOA ismerte- 
tésénél az alapértelmezett értékeket: 

Refresh-15 perc, retry-10 perc, expire-1 nap. Akinek ez 
nem tetszik, kattintson jobb gombbal a zónáján, Proper- 
ties, ás állítsa át. Az 1 napnyi expire valóban elég kevés 
lehet, hisz így egy primary-secondary páros nem él túl 
egy hétvégét, ha a primary elhal. 
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BT Windowszao 
2lad 
WINS 1 Zone Transfers Securly ] 
General Start of Authority (S0A) ]  NameServers  ] 
Serial number: 
Increment 
Ptimary server: 
platán netacademia Ím. Browse... 
Responsible person 
fm netacademia fm. Browce... 
Refresh intervat 15 [minutes . 
Rety intervat 10 [minutes - 
Expires after: 1 days . 
Minimum (defaut) TTL: D 10 0 
ITL for this record: p 1 0 0 








Lex ]. crea [/ és ] 


Levelezés-szervező (MX) 

Segíti az üzenetek útvonalának kiválasztását a céltarto- 
mányban lévő levelezés-kiszolgálóhoz. Ha több ilyen is 
létezik, akkor a köztük fennálló sorrendiséget a kétjegyű 
preferencia-értékek határozzák meg. Mindegyik MX re- 
kordhoz tartoznia kell egy ugyanabban a zónában talál- 
ható A rekordnak is. 

szintaxis: tulajdonos MX preferencia-érték levelezés-ki- 
szolgáló neve 

példa: falatrax MX 10 mail.falatrax.hu 

Fordított névátalakításra használják, a tulajdonos mezőben 
szereplő IP címet egy DNS névhez kapcsolja. Többnyire 
csak az in-addr.arpa tartományban találkozhatunk vele a 
címsznév összerendelések fordított lekérdezésénél. Leg- 
többször egy normál lekérdezési zónában lévő A rekordra 
mutat. 

szintaxis: tulajdonos PTR céltartomány neve 

példa: 200 PTR masina. falatrax.hu 

Lehetővé teszi egy adott szolgáltatást nyújtó kiszolgáló, 
például egy Windows 2000 Active Directory tartományve- 
zérlő azonosítását. Segítségével a hasonló, TCP/IP alapú 
szolgáltatásokat biztosító kiszolgálók listája egyetlen 
DNS lekérdezéssel kideríthető. Elsősorban a Windows 
2000 AD igényli a jelenlétét, ahol az összes releváns DNS 
rekord automatikusan bekerülhet a DNS-be. 

szintaxis: szolgáltatás.protokoll.név TTL SRV prioritás ter- 
heléselosztási súly port cél 

példák: 

1. ldap. tcp.dc. msdcs 600 SRV 0 100 389 masina. falat- 
rax.hu 

2. 600 SRV 0 100 389 csodagep.falatrax.hu 

3. 600 SRV 0 100 389 hilo.falatrax.hu 


DNS üzenetek 
DNS üzenetet két DNS kiszolgáló, illetve egy DNS kiszolgá- 
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ló és egy DNS ügyfél küldhet egymásnak, rendszerint UDP 
protokollal, az 53-as porton keresztül. Egyes esetekben, 
különösen a válaszokban, az üzenet hosszúsága meghalad- 
hatja az UDP csomag adatmezőjének nagyságát. Az üzenet 
datja. Az ügyfél ezután újra érintkezésbe lép a kiszolgáló- 
val az 53-as porton, de most már TCP kapcsolatot épít ki, 
és megismétli a lekérdezést. A TCP protokollal hosszabb 
adatfolyamok is biztonságosan továbbíthatók. Ez a megol- 
dás a két átviteli protokoll előnyeit egyesíti: kis adat- 
mennyiségnél az UDP hatékonysága, míg hosszabb adatfo- 
lyamnál a TCP megbízhatósága emelkedik ki. 


A DNS üzenetek felépítése 

A DNS eredetileg kézzel frissített, statikus adatok dinami- 
kus lekérdezésére szolgált, amihez kétféle üzenetet hasz- 
náltak: lekérdezést és választ. A dinamikus frissítéssel 
együtt megjelent a frissítési üzenet, amelynek szerkezete 
a lekérdezésekére vezethető vissza. Emiatt csak a két fő 
üzenettípus felépítését mutatjuk be. 

A DNS lekérdezések felépítése 

Az DNS lekérdezések felépítése az alábbi ábrán látható 
formát követi. Az üzenet fejléce mindig 12 bájt hosszú, 
míg a lekérdezéseket és a válaszokat tartalmazó, további 
rész nagysága változó. 





párbeszéd azonosító állapotjelzők 





leérdezés-számláló válaszrekord-számláló 


12 bájt 


kiegészítő rekord számláló 


felügyelt rekord számláló 





lekérdezések (változó hosszú) 


válaszrekordok (változó hosszú) 





felügyelt rekordok (változó hosszú) 





Változó hosszú 


KN kiegészítő rekordok (változó hosszú) 

A DNS lekérdezések általános felépítése 

A DNS üzenetek fejléce 

A DNS üzenetek fejlécét a következő, 16 bites mezők alkotják: 
"b A párbeszédazonosító a DNS tranzakciók megkülön- 
böztetésére szolgál. A kapcsolat kezdeményezője hoz- 
za létre, és a másik fél is ugyanezt az értéket helyezi 
el a válaszban. Több tranzakció egyidejű bonyolítása- 
kor ennek a számnak a segítségével állíthatók párba a 
kérések és válaszok. 

Állapotjelzők (lásd ábra) 

A lekérdezés-számláló megmutatja, hány bejegyzés 
található a DNS üzenet kérdés részében. 

A válaszrekord-számláló jelzi, hogy hány bejegyzés 
került a válasz válaszrekordok részébe. 

A felügyelt rekord számláló a kiszolgáló felügyelete alá 
tartozó rekordok számát adja meg. 

A kiegészítő rekord számláló értéke az üzenetben lévő 
egyéb rekordok száma. 

A jelzők mezőben lévő állapotjelzőkből a kiszolgáló vagy az 
ügyfél fontos következtetéseket vonhat le: 


dd 


öö 


S.) 


A 
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kérés/válasz 
műveleti kód 
hatásköri válasz 
csonkolás 
rekurziókérés 


z 1bit 


rekurzió lehetséges 
foglalt 0 0 0 
visszatérési kód 
A DNS üzenetek állapotjelzői 
"b Kérés/válasz: Névszolgáltatási kérést jelez, ha értéke 
0x0, és választ, ha 0x1. (1 bit) 


"0 Műveleti kód: A névszolgáltatási művelet típusát hatá 
rozza meg (4 bit). 


0x0o  — lekérdezés 
0x1 inverz lekérdezés 
0x2 kiszolgálóállapot-lekérdezés 


"? Hatásköri válasz: A kiszolgáló ezzel jelzi a válaszban, 
hogy a kérdés részben szereplő tartománynév az ő 
felügyelete alá tartozik-e? (1 bit) 

Csonkolás: 0x1 értéke azt jelzi, hogy a teljes válasz 

nem fér bele egy UDP csomagba. Ekkor csak a válasz el- 

ső 512 bájtja kerül a csomagba. (1bit) 

"b Rekurziókérés: Rekurzív lekérdezésnél értéke 0x1. Ha 
értéke 0x0, és a megszólított névkiszolgálónak nem 
tartozik a hatáskörébe a kérés, akkor az azoknak a DNS 
kiszolgálóknak a listáját küldi vissza, amelyek sikerrel 
válaszolhatnak. Ez a delegáció kezelésének módja a 
névátalakítás folyamatában. (1bit) 

"0 Rekurzió lehetséges: A DNS kiszolgálók a 0x1 érték 

beállításával jelzik, hogy képesek kezelni a rekurzív ké- 

réseket. (1 bit) 

Foglalt: Ahogy a neve is mutatja, nem használható, ér- 

téke mindig 0x0. (3 bit) 

"9 Visszatérési kód: A 0x0 érték a sikeres válasz jele 
(névlekérdezésnél ez például azt jelenti, hogy a cím 
megtalálható a válaszban). A 0x3 értéket akkor veszi 
fel, ha a hatásköri DNS kiszolgáló nem talál rekordot a 
lekérdezett névhez. 

A DNS lekérdezések kérdésbejegyzései 

A DNS lekérdezés tárgyát képező tartománynév a kérdésbe- 

jegyzésben található. 


kérdésnév 
kérdéstípus z 1bit 
kérdésosztály 


A kérdésmező szerkezete 


"8 Kérdésnév: A lekérdezett tartománynév helye. Koráb- 
ban szó esett már róla, hogy a DNS tartománynevek 
címkék sorozatából állnak (a falatrax.hu például a fa- 
latrax és hu címkékből) . A kérdésnév mezőben a címké- 
ket azok hossza előzi meg, a pontok kimaradnak, és a 
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karaktersorozatot 0 zárja. A falatrax.hu például így néz 
ki: Ox8falatraxox2huOxo. 

8 Kérdéstípus: Meghatározza, hogy a válaszban milyen 
rekordoknak kell szerepelni. 


0x01 címrekord (A) 
0x02 névkiszolgáló (NS) 
0x05 alias (CNAME) 


0x0C (12) mutató (PTR) 
OxOF (15) levelezés-szervező (MX) 
0x21 (33) szolgáltatásazonosító (SRV) 
OxFB (251) növekményes zónaátvitel (IXFR) 
0xFC (252) standard zónaátvitel (AXFR) 
OxFF (255) minden rekord 
8 Kérdésosztály: Értéke általában 0x00-01, ami az 
IN osztályt jelzi. 
Erőforrásrekordok 


erőforrásrekord-név (változó hossz) 
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adatmező (változó hossz) 

A DNS erőforrásrekordok felépítése 
A DNS kiszolgáló válaszüzenetének válasz-, hatásköri és 
kiegészítő részébe kerülnek a kérés feldolgozásának ered- 
ményét képező rekordok, melyek szerkezetét a 7. ábra 
szemlélteti. 
"B Erőforrásrekord-név: Változó hosszúságú mező, amely a 
DNS tartománynevet tartalmazza, az előző részben ki- 
fejtett kérdésnév mező formátuma szerint. 
Rekordtípus: lásd a kérdéstípust az előző részben. 
Rekordosztály: Jelenleg csak egy kódot használunk 
(0x00-01) az Internet osztály jelölésére. 
8 TTL: A rekord felhasználhatóságát határozza meg má- 

sodpercben kifejezve. 
"2 Adatmezőhossz: Az erőforrásadatok nagyságát adja meg. 
"2 Adatmező: A rekordtípus szerinti, változó nagyságú adat. 


SB 


A DNS frissítési üzenet felépítése nagyon hasonlít a lekér- 
dezésekéhez, sok mező teljesen megegyezik. A fejléc hatá- 
rozza meg a frissítési műveletet, a rekordmezők hordozzák 
a változásokat. 
KT párbeszédazonosító 


állapotjelzők 





zónabejegyzés-számláló 


szükséges rekord számláló 


12 bájt 








frissített rekord számláló T. kiegészítő rekord számláló 


zónabejegyzések (változó hosszú) 








szükséges rekordok (változó hosszú) 


frissített rekordok (változó "hosszú ) 





Változó hosszú 


kiegészítő rekordok (változó hosszú) 
A DNS frissítési üzenet általános felépítése 
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ZD] Windowszoo 


A DNS frissítés állapotjelzői 
A DNS frissítési üzenet állapotjelzők mezőjében a lekérde- 
zéséhez hasonló állapotjelzőket találunk. 
kérés/válasz 

műveletikód 0 1 0 1 


foglalt 0 000000 
visszatérési kód 


z 1bit 


A DNS frissítés állapotjelzői 

"b Kérés/válasz: Frissítési kérést jelez, ha értéke 0x0, és 

választ, ha 0x1. (1 bit) 

Műveleti kód: 0x5 értéke jelzi a frissítést. (4 bit) 

Visszatérési kód: A frissítési kérelmekre adott válasz 

eredménye. 

0x0 Afrissítés hibátlanul sikerült. 

0x1 Formátumhiba - a DNS kiszolgáló nem érti az 
üzenetet 

0x2  — ArKkérelem feldolgozása közben a DNS kiszolgáló 
hibát észlelt. 

0x3 Nem létezik az a név, aminek kellene. 

0x4 —— Nem támogatott műveleti kód. 

0x5 Biztonsági okokból, illetve a házirend miatt a 
DNS kiszolgáló a műveletet nem hajthatja végre. 

0x6 Létezik az a név, aminek nem kellene. 

0x7 Létezik az a rekordcsoport, aminek nem kellene. 

0x8 Nem létezik az a rekordcsoport, aminek kellene. 

0x9 — A zóna részben megadott zóna nem tartozik a 
kiszolgáló hatáskörébe. 

OxA A szükséges, illetve a frissített rekordok 
mezőkben lévő név nem található a zóna 
mezőben szereplő zónában. 

Névlekérdezési üzenet 

A névlekérdezési üzenet az RFC 1034-ben leírt formátumot 

használja, ami megegyezik a DNS lekérdezési üzenetével. A 

névátalakításnál bemutatott NM napló éppen a névlekérde- 

zést mutatja be, ahol a következő mezőket találjuk: 

"b Lekérdezés-azonosító: Egyedi szám, ami alapján az 
átalakító program párba tudja rendezni a lekérdezése- 
ket és válaszokat. 

0 Állapotjelzők: Többek között a standard lekérdezés és 

a rekurziókérés jelzésére szolgál. 

Kérdésbejegyzés-számláló: Értéke 1. 

Kérdésrész: Itt kell elhelyezni az átalakítandó tarto- 

mánynevet (a példában masina.falatrax.hu) és vissza- 

küldendő rekordokat (A címrekord). 

Névlekérdezési válaszüzenet 

Az átalakítók a névlekérdezésre ilyen üzenettel válaszolnak, 

a lekérdezési üzenettel azonos formátumban. A névátalakí- 

tásnál található NM napló második felében tanulmányoz- 

hatjuk a válasz felépítését, amelyben a mezők jelentése: 

B Lekérdezés-azonosító: Egyedi szám, ami alapján az 
átalakító program párba tudja rendezni a lekérdezése- 
ket és válaszokat. 

"8 Állapotjelzők: Ezekkel lehet jelezni, hogy válaszról van 
szó, és az átalakítás sikeresen befejeződött. 


8 


A 


8 


JA 
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Kérdésbejegyzés-számláló: Értéke 1. 

Válaszbejegyzés-számláló: Értéke 1. 

Kérdésrész: Megegyezik a lekérdezési üzenetben lévő 

kérdésrésszel. 

Válaszrész: Ide kerülnek a lekérdezésben kért rekordok 

(példánkban a címrekord, amelyben megtaláljuk a kérdé- 

ses tartomány IP címét). 

Az aliasok részben is tanulmányozhat az olvasó egy lekér- 

dezés-válasz naplót, amely egy kicsit különbözik az előző- 

től. Ebben az átalakító az ns1.falatrax.hu-hoz tartozó A re- 
kordot próbálja keresi, de csak egy CNAME rekordot talál. 

A válaszba azért emellett még a kanonikus névhez tartozó 

A rekordot is beleteszi. 

Fordított lekérdezési üzenetek 

A fordított lekérdezési üzenetek szerkezete megegyezik a 

normál lekérdezésekével, mindössze két különbség van: 

"0 A ccltartomány neve más: az átalakító a fordított le 
kérdezéseknél a kérdéses IP cím alapján in-addr.arpa 
tartománynevet hoz létre. 

"8 A válaszba nem A, hanem PTR rekord kerül. 

A fordított lekérdezésre adott válaszüzenetek felépítése 

megegyezik a normál válaszüzenetekével, de az A helyett 

PTR rekordot tartalmaz. 

Névfrissítési üzenet 

A névífrissítési üzenetek formátumát az RFC 2136 határoz- 

za meg, amin már túlestünk a DNS frissítési üzenetek 

felépítésének tárgyalásakor. Például szolgáljon a DNS dina- 
mikus frissítéséről szóló részben látható NM napló, mely- 
nek legfontosabb mezőit így kell beállítani: 

"1 Lekérdezés-azonosító: A lekérdezési üzenethez hason- 
lóan, ennek is van azonosítója, hogy a küldő a választ 
az eredeti kérdéshez tudja rendelni. 

0 Állapotjelzők: A kérés tényét, és a dinamikus frissítést 
ezekkel tudjuk jelezni. 

A Frissítési zóna: Értéke 1, és a zónarészben van a frissí- 
tendő zóna. 

B Kötelező zóna: Értéke 2, két kötelező kell megadni. 

B Frissítendő zóna: A frissítendő zóna rekordja. 

Névfrissítési válaszüzenetek 

A névfrissítési válaszüzenetekhez a DNS dinamikus frissítésé- 

ről szóló rész NM naplóját vesszük példának. Ebben a válasz 

azonos a kéréssel, eltekintve attól, hogy a válasz fejlécében 
lévő állapotjelzők egyike a művelet sikerességét adja tudtul. 

Ellenkező esetben a válasz a hibaüzenetet tartalmazza. 


dHPod 


ő) 


Összefoglalásul 

A DNS korábban csak lehetőség volt a WINS-t használó 
Windows NT hálózatokban a legtöbb tartományművelet, il- 
letve a nyomtató- és fájlmegosztás megvalósítására, míg a 
Windows 2000 hálózatokban már kulcsfontosságú szerepet 
tölt be, és a Windows 2000 Active Directory telepítéséhez 
nélkülözhetetlen. 


Fóti Marcell 
marcellf(onetacademia.net 
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A felhasználói, illetve a számítógépes beállítások 
központi kezelése már a Windows NT 4.0-ás kör- 
nyezetben is jól használható volt. A Windows 


valt 2000 csoportos házirendje (Group Policy) lé- 


nyegesen fejlettebb az NT-ben található 
System Policy-hoz képest. A csoportos házi- 
rend segítségével már nem csak a regisztrá- 
ciós adatbázis bejegyzéseinek értékeit tudjuk 
módosítani, hanem lehetőségünk van például 
programok telepítésére vagy logon, logoff, startup 

és shutdown scriptek központi kezelésére is. 

Az úgynevezett sablonfájlok (administrative templates) ha- 

tározzák meg, hogy a regisztrációs adatbázisban mely beál- 

lítások változtathatók meg a System Policy Editor, illetve a 

Group Policy MMC modul segítségével. A System Policy Edi- 

tor és a Group Policy MMC modul alapértelmezésben az 

alábbi sablonfájlok használatát kínálják fel: 

I Common.adm (System Policy): NT 4.0, Windows 95 és 
98 operációs rendszereknél is használható. Elsősorban 
felhasználói felületre vonatkozó tiltásokat tartalmaz. 

"0 Winnt.adm (System Policy): NT 4.0 operációs rendszer 
esetében a Shell, System és Profile kategóriákban tud- 
juk a beállításokat módosítani. 

"0 System.adm (Group Policy): Ebben a sablonban a Win- 
dows 2000 operációs rendszer beállításai találhatók meg. 

"0 Inetres.adm (Group Policy): Az Internet Explorer bön- 
gészővel kapcsolatos tiltások gyűjteménye. 

"0 Conf.adm (Group Policy): A NetMeeting beállításait 
tartalmazza. 

Természetesen új sablonokat is létrehozhatunk, ha elsajá- 

títjuk a szerkesztésük fortélyait. Cikkünkkel ebben szeret- 

nénk segítséget nyújtani. Egyszerű példákkal szemléltetve 
részletesen bemutatjuk az utasítások használatát. Hogy az 
utasítások kipróbálásakor nehogy problémák jelentkezzenek 
az operációs rendszer működésében, a cikkben szereplő pél- 
dák alkalmazásakor a regisztrációs adatbázisban egy funk- 
ció nélküli kulcs alatt jelennek meg próbabejegyzéseink. A 
sablonfájlok szerkesztését az egyszerűség kedvéért a Sys- 
tem Policy Editor felületén keresztül mutatjuk be, de a pél- 
dák kipróbálhatók a csoportos házirendben is. Figyelembe 
kell venni azonban, hogy a Windows NT-vel szemben a Win- 
dows 2000 operációs rendszernél az új típusú csoportos há- 
zirendbeállításoknak kitüntetett helyük van a regisztrációs 
adatbázisban. A felhasználóra (HKEY. CURRENT USER hive) 
és a számítógépre (HKEY LOCAL MACHINE hive) vonatkozó 
bejegyzések a MSoftwareXPolicies, illetve a YSoftwareWic- 
rosoftWindowsMXurrentVersion Policies kulcsok alatt je- 
lennek meg. Erre a változtatásra azért volt szükség, hogy 
elkerülhető legyen a régebbi System Policy egyik kellemet- 
len hibája. A Windows NT 4.0-ás környezetben gyakran elő- 
fordult, hogy a házirend megváltozásakor a régi bejegyzé- 
sek megmaradtak a regisztrációs adatbázisban. Az új típu- 
sú házirend beállításoknál ez a probléma már nem fordulhat 
elő, sőt a házirendfájl letörlése esetén az általa kiváltott 
hatás is visszavonódik. (Fogalmazhatunk úgy is, hogy az új 
típusú házirend az operációs rendszer tudtával és vezetésével 
végzi dolgát, így mindig konzisztens önmagával, míg a régi - 
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megtűrt kiegészítésként - egyszerűen ,,alátesz" az NT4 op- 
rendszernek - a hatás visszavonása egy ellentétes hatású 
valátevéssel" szüntethető meg - a szerk). Ugyanakkor az új 
csoportos házirendhez is készíthetünk olyan sablont, amely 
nem az erre fenntartott helyeken változtatja meg a regiszt- 
rációs adatbázisban a bejegyzéseket, hanem - ugyanúgy 
mint régen - tetszőleges helyeken módosíthatja azt. Ha 
ilyet használunk, figyelembe kell vennünk, hogy bizonyos 
esetekben a házirend megváltozásakor a korábbi beállítások 
is megmaradhatnak (a regisztrációs adatbázis ,,tetoválására" 
kerül sor — a szerk.) . Éppen e kellemetlen mellékhatás miatt 
a régi típusú házirendbeállítások alapértelmezésben nem je- 
lennek meg a csoportos házirend felhasználói felületén, 
hogy nehogy összekeverjük, és véletlenül használjuk ezeket. 
A View menü Show Policies Only parancsával lehet megjele- 
níteni, illetve eltüntetni minden régi típusú bejegyzést: 
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A régi típusú házirendbeállítások megjelenítése és 
eltüntetése 


A felhasználói felületen piros ikonnal jelenik meg minden 
olyan beállítás, amely nem az erre fenntartott kulcsok alatt 
módosítja a regisztrációs adatbázist. 


A System Policy Editor működésének áttekintése 
A házirendbeállítások alapját képező sablonfájlokat a Poli- 
cy Editor felhasználói felületén az Options menü Policy 
Template parancsával tudjuk betölteni, illetve szükség ese- 
tén eltávolítani. A házirendbeállításokat tartalmazó fájl lét- 
rehozásakor alapértelmezésben csak a Default User és a De- 
fault Computer ikon jelenik meg. Az Edit menü Add User, 
Add Computer, Add Group parancsaival tudunk új felhasz- 
nálót, számítógépet, illetve globális felasználói csoportot 
hozzáadni. Érdemes figyelni arra, hogy az általunk beírt ne- 
vek valódiságát sajnos nem ellenőrzi a program. A fájlt 
Windows NT 4.0-ás környezetben ntconfig.pol néven kell el- 
mentenünk, mégpedig a NETLOGON megosztás alá. 
A házirend szerkesztése nagyon egyszerű: ha a megfelelő 
ikonra kettőt kattintunk, akkor megjelennek a rendelkezés- 
re álló beállítások. Minden beállításnak három állapota van: 
"8 Engedélyezett (Enabled): A jelölőnégyzetben kis pipa 
látszik. 
8 Letiltott (Diasbled): A jelölőnégyzet fehér. 
-B Érintetlen (Not Configured): A jelölőnégyzet szürke. 
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Ebben az állapotban a regisztrációs adatbázisban sze- 
replő értékek változatlanok maradnak. 
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A beállítás három lehetséges állapota 


A házirend beállításai az alábbi szabályszerűségek alapján 

érvényesülnek: 

"0 Ha csak a Default Usert, illetve a Default Computert 

használjuk, akkor a beállítások a tartomány összes fel- 

használójára és számítógépére érvényesek lesznek. 

Abban az esetben, ha ugyanaz a beállítás eltérő érté- 

ket kap a Default User és valamelyik globális csoport 

esetében, akkor a globális csoport beállítása érvényesül. 

Ha például a Default User-nél a Logon, míg a Domain 

Admins csoportnál a Blank képernyővédőt állítjuk be, a 

rendszergazdáknál a Blank képernyővédő jelenik meg. 

"0 Hasonlóan az előbbi esethez, az egyedi felhasználó 
beállításai felülírják a Default User-ét. 

"0 Az egyedi felhasználó beállításai mindig előnyt élvez- 
nek a csoporttal és a Default User-rel szemben, függet- 
lenül attól, hogy a beállításokat módosítjuk-e vagy sem. 

0 A globális csoportoknál, ha a beállítások átfedik egy- 
mást, akkor a rangsorban előrébb lévő csoportnál meg- 
határozott értékek íródnak a regisztrációs adatbázisba. 
A csoportok sorrendiségét a System Policy Editor Opti- 
ons menü Group Priority menüpont alól elérhető pár- 
beszédablakban állíthatjuk be. 

0? Ha valamelyik beállítást a csoportok szintjén nem vál- 
toztatjuk meg (a jelölőnégyzet szürke), a Default User 
esetében viszont engedélyezzük, akkor a Default User- 
nél megadott érték kerül a registrybe. Ez a szabály- 
szerűség a szóban forgó csoport azon tagjára nem vo- 
natkozik, amelyet egyedileg is felvettünk a házirend 
beállításait tartalmazó fájlba. Ilyenkor a csoport és a 
Default User beállításai nem érvényesülnek. 

"B Ha a ccsopotok szintjén megadott beállítások nem fedik 
át egymást, akkor a végrehajtás során összeadódnak. 

"0 Adott csoportsorrend esetén, a rangsorban hátul lévő 
csoportnál engedélyezett beállítás akkor érvényesül, 
ha a sorban előrébb lévő csoportok esetében a szóban 
forgó beállítást nem módosítjuk. 


m 
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A sablonfájl alapegységei 

A házirenden keresztül a regisztrációs adatbázis felhaszná- 
lóra (HKEY CURRENT USER hive) vagy a számító- 
gépre vonatkozó (HKEY LOCAL MACHINE hive) ré- 
szét tudjuk módosítani. A sablonfájlban a CLASS 
User vagy a CLASS Machine utasítással adhatjuk 
meg, hogy a bejegyzéseket melyik hive alatt sze- 
retnénk megváltoztatni. 

Az összetartozó beállításokat csoportokba szervez- 
hetjük. A csoport kezdetét a CATEGORY, végét az 
END CATEGORY jelzi. Természetesen minden kate- 
góriának nevet kell adnunk, amelyet többfélekép- 
pen is megtehetünk. A CATEGORY után álló karak- 
tersort a System Policy Editor a kategória neveként 
azonosítja. Például: CATEGORY Kategória Neve. Ab- 
ban az esetben, ha a karaktersor szóközt is tartal- 
maz, akkor idézőjelek közé kell tennünk. Például: 
CATEGORY "Kategória Neve". A név megadásának 
ilyen formája egyszerű és kézenfekvő, ennek elle- 
nére nem ez az általánosan elfogadott gyakorlat. A kate- 
górianév helyén minden esetben egy szöveges változó áll, 
amelynek a sablonfájl végén, az úgynevezett [Strings] 
szekcióban adunk értéket. A szöveges változó mindig dup- 
la felkiáltójellel kezdődik, majd ezt követi a változó neve: 


0 


CLASS User 
CATEGORY !!CategoryName 


END CATEGORY 


Istrings] 
CategoryName - ,Első kategória" 


Egy szöveges változót a sablonon belül többször is hasz- 
nálhatunk. A kategóriák tetszőleges mélységig egymás- 
ba ágyazhatók, amelyek a Policy Editor felhasználói fe- 
lületén kinyitható, illetve bezárható, kék színű könyv 
formájában jelennek meg. 

A kategóriák alatt tűnnek fel a házirendbeállítások, ame- 
lyek előtt egy jelölőnégyzet látható. Ezzel tudjuk megha- 
tározni, hogy az adott beállítás érvényesüljön-e vagy sem. 
A jelölőnégyzetet a POLICY kulcsszóval hozzuk létre, amelynek 
nevét az általánosan elfogadott gyakorlat szerint szöveges vál- 
tozó segítségével határozzuk meg. A kategóriához hasonlóan 
a POLICY blokk végét az END POLICY-val kell jeleznünk. 

A házirend használatának egyszerűsítése végett sokszor le- 
hetőséget kell teremtenünk arra, hogy a felhasználói felü- 
leten keresztül is megadhassunk értékeket. Az ilyen jelle- 
gű adatbeviteli lehetőséget a PART kulcsszóval tudunk lét- 
rehozni. Az eddigiekhez hasonlóan a PART nevét is szöve- 
ges változóval szokás megadni. A PART-nak számos típusa 
van (például EDITTEXT, LISTBOX, stb), amelyet az elnevezés 
után tüntetünk fel: 


PART !!PartName LISTBOX 


END PART 
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Az egyes típusokról és használatukról a későbbiekben rész- 
letesen is szó lesz. 

A regisztrációs adatbázis sok bejegyzésének csak két értéke 
lehet: nulla vagy egy. Előfordul azonban, hogy egy beállítás 
engedélyezése a házirendben számos érték megváltozását 
vonja maga után a regisztrációs adatbázisban. Máskor nem 
elegendő, ha a sablonfájlba közvetlenül adjuk meg az érté- 
keket, a felhasználói felületen is kell változtatási lehetősé- 
get biztosítanunk. Az értékadásnak különböző formái van- 
nak tehát, amelyeket egyszerű példákon keresztül fogunk 
áttekinteni. Elkerülendő, hogy a példák kipróbálásakor zavar 
támadjon a számítógépek működésében, bejegyzések a 
HKEY CURRENT USERVAdnTEeszt kulcs alá kerülnek. A házi- 
rend végrehajtásakor az AdmTeszt kulcs automatikusan lét- 
rejön. Ezt azután a Registry Editorral lehet törölni, mivel a 
házirenden keresztül kulcstörlés nem valósítható meg. 


Az értékadás egyszerű formái 

A legegyszerűbb esetben az értékadáshoz elegendő megha- 
tároznunk a regisztrációs adatbázis megfelelő kulcsának az 
a bejegyzés típusa REGDWORD, értéke pedig 1 lesz. A beál- 
lítás letiltása során a bejegyzés törlődik a registryből. 
amely a CATEGORY, POLICY és PART kulcsszavak után is 
szerepelhet. A CATEGORY szintjén meghatározott elérési út 
az egész kategóriára érvényes lesz. Ezt azonban felül tud- 
juk bírálni, például a POLICY kulcsszó után megadott má- 
sik útvonallal. Ez az új elérési út természetesen nem vo- 
natkozik más beállításokra is. A KEYNAME után az elérési 
utat csak akkor kell idézőjelbe tenni, ha valamelyik kulcs 
nevében szóköz is szerepel. 

A bejegyzés nevét a VALUENAME utáni karaktersor határoz- 
za meg. Bár idézőjelet itt is csak akkor kell használni, ha 
az elnevezés szóközt is tartalmaz, az egységes kezelés ér- 
dekében érdemes minden esetben alkalmazni. 


CLASS User 
CATEGORY !!SSamples 
KEYNAME "ADMTeszt" 
POLICY !!Samplel 
VALUENAME "SamplelőValue" 
END POLICY 
END CATEGORY 


[strings] 
SsSamples - "Példák" 
Samplel - "Példa 1: Policy" 


Ha az alapértelmezettől eltérő típusú vagy értékű bejegyzést 
szeretnénk létrehozni vagy megváltoztatni, akkor a 
VALUEON, illetve a VALUEOFF utasításokat kell alkalmaznunk: 
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POLICY !!Sample2 
VALUENAME "Sample2ZőValue" 
VALUEON NUMERIC 1 
VALUEOFF NUMERIC 0 
END POLICY 


Az iménti példában is REG DWORD típusú bejegyzés jön lét- 
re. A beállítás érvénytelenítése után viszont már nem tör- 
lődik a bejegyzés, hanem nulla értéket vesz fel. Ha elhagy- 
juk a NUMERIC kulcsszót, akkor a bejegyzésünk REG SZ tí- 
pusú lesz. Figyeljünk arra, hogy, hogy a NUMERIC után min- 
dig decimális formában kell beírni az értéket. Ha a házirend 
letiltásakor az első példához hasonlóan törölni szeretnénk 
a bejegyzést, akkor vagy a VALUEOFF DELETE parancsot kell 
használnunk vagy hagyjuk el a VALUEOFF NUMERIC 0 sort. 
Amennyiben a beállítás engedélyezésekor valamelyik be- 
jegyzést szeretnénk törölni a regisztrációs adatbázisból, ak- 
kor írjuk a VALUEON után a DELETE kulcsszót. 

Olyan eset is előfordulhat, hogy egy beállításhoz több be- 
jegyzést is létre kell hoznunk a regisztrációs adatbázisban. 
Ezt a problémát az ACTIONLISTON és az ACTIONLISTOFF pa- 
rancsokkal tudjuk megoldani. 


POLICY !!Sample3 
KEYNAME "ADMTesztlactionlist" 
VALUENAME "ActionListState" 
ACTIONLISTON 
VALUENAME "ALőValue4" VALUE NUMERIC 1 
VALUENAME "ALőValue5" VALUE NUMERIC 
VALUENAME "ALőValue6" VALUE NUMERIC 3 
END ACTIONLISTON 
ACTIONLISTOFF 
VALUENAME "ALőValue4" VALUE NUMERIC 0 
VALUENAME "ALőValue5" VALUE NUMERIC 0 
VALUENAME "ALőValue6" VALUE NUMERIC 0 
END ACTIONLISTOFF 
END POLICY 


n 


Az ACTIONLISTON és ACTIONLISTOFF utasítások alkalmazá- 
sakor az értéket minden esetben a VALUE kulcsszóval kell 
megadnunk. A bejegyzés törlésére vonatkozó szabályok 
megegyeznek a VALUON, VALUEOFF parancsoknál leírtak- 
kal. A System Policy Editor sajátságosan kezeli az ACTION- 
LISTON, ACTIONLISTOFF utasításokat. Ha mentés után is- 
mét megnyitjuk az ntconfig.pol fájlt, akkor tapasztalni 
fogjuk, hogy a jelölőnégyzet szürke lesz, függetlenül attól, 
hogy milyen beállítással mentettük el korábban. A beállí- 
tás eljut ugyan a felhasználókhoz, de a felhasználói felü- 
leten nem látszik, hogy kinek engedélyeztük. A problémát 
úgy tudjuk áthidalni, hogy a regisztrációs adatbázisban el- 
tároljuk az Actionlist aktuális állapotát. Erre szolgál a fen- 
ti példában az ,ActionListState" változó. Tapasztalataim 
szerint a Group Policy-nál már megszűnt ez a probléma. 
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Értékadás a grafikus felületről 

A PART különböző típusaival változatos adatbeviteli lehe- 
tőséget biztosíthatunk a rendszergazdák számára, így az 
értékek esetleges változásakor nem kell a sablonfájlt mó- 
dosítani. A sablonfájl strukturális felépítéséből adódóan a 
PART minden esetben a POLICY kulcsszó után szerepel. A 
PART elnevezését a korábban már említett gyakorlatnak 
megfelelően szöveges változó formájában szokás megadni. 
Közvetlenül a név után kell meghatároznunk a PART típu- 
sát, amelyet az alábbiak közül választhatunk ki: 

"8 CHECKBOX 

"0 EDITTEXT 

"2 DROPDOWNLIST 

COMBOBOX 

-£ LISTBOX 

I NUMERIC 

"3 TEXT 

Az értékadáshoz természetesen szükséges a bejegyzés ne- 
vének az ismerete, amelyet itt is a VALUNAME segítségével 
adunk meg. Mint később látni fogjuk, ez alól csak a LIST- 
BOX és a TEXT típusok képeznek kivételt. Figyeljünk arra, 
hogy ha a POLICY szintjén is szerepel a VALUENAME, akkor 
két bejegyzés jön létre a regisztrációs adatbázisban. 


b 


POLICY !!Sample4 
VALUENAME "Policy Value" 


PART !!Partl EDITTEXT 
VALUENAME "EditTextőValue" 
END PART 
END POLICY 


A fenti beállítás engedélyezésekor PolicyValue és 
EditText Value néven is létrejön egy bejegyzés a regisztrá- 
ciós adatbázisban. 


CheckBox 

Használatával egy jelölőnégyzet jelenik meg a Policy Edi- 

tor párbeszédablakának alsó részén. Alapértelmezésben 

REG DWORD típusú bejegyzést hozhatunk létre, melynek 

értéke 1 lesz. Ha a jelölőnégyzet üres, akkor a bejegyzés 

törlődik a regisztrációs adatbázisból. A CHECKBOX típus es- 
tén az alábbi parancsokat használhatjuk: 

0 ACTIONLISTON, ACTIONLISTOFF: Lehetőséget ad egyi- 
dőben több bejegyzés értékének megváltoztatására a 
jelölőnégyzet kiválasztásakor, illetve a kiválasztás 
megszüntetésekor. 

"I DEFCHECKED: A jelölőnégyzet automatikusan kijelölt 
állapotba kerül. 

"8 VALUEON, VALUEOFF: Akkor használjuk, ha a bejegyzés 
alapértelmezett típusát vagy értékét szeretnénk meg- 
változtatni. 
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POLICY 
KEYNAME "ADMTesztiCheckBOox" 

PART !!CheckBoxőPart CHECKBOX 
VALUENAME "CheckboxőValue" 
VALUEON 
VALUEOFF 

END PART 

END POLICY 


1!Sample5 


"vőon" 


"vőoff" 


A fenti példában Checkbox Value néven hozunk létre 

REG SZ típusú bejegyzést a regisztrációs adatbázisban, 
melynek értéke a jelölőnégyzet állapotától függően ,v on" 
vagy ,v. off" lesz. 


EditText 

Szerkeszthető mezőt tudunk vele megjeleníteni. A regiszt- 
rációs adatbázisban REG SZ vagy REG EXPAND SZ típusú 
bejegyzés jön létre. Az utóbbi típust akkor érdemes hasz- 
nálni, ha rendszerváltozót szeretnénk megadni a mezőben 
(például 9oSystemroot9o). Az EDITTEXT típus gyakran hasz- 
nálatos parancsai a következők: 

- DEFAULT cértékz: Meghatározhatjuk, hogy alapértel- 
mezésben milyen érték jelenjen meg a mezőben. 
REOUIRED: A beállítás engedélyezésekor a mezőt ki 
kell tölteni. 

"8 EXPANDABLETEXT: A regisztrációs adatbázisban az alap- 
értelmezett REG SZ helyett REG EXPAND SZ típusú be- 
jegyzés jön létre. 

MAXLEN cértékz: A mezőbe beírható karakterek maxi- 
mális számát tudjuk meghatározni. 


3 


We, 


Az alábbi példában egy olyan szerkeszthető mezőt hozunk 
létre, amelynek kitöltése kötelező, és maximum tíz karak- 
tert tartalmazhat: 


POLICY !!Sample6 
KEYNAME "ADMTesztlEditText" 
PART !lEditTextőPart  EDITTEXTREOUIRED 
VALUENAME "EditText Value" 
MAXLEN 10 
END PART 
END POLICY 


folytatjuk... 


Tomasz Balázs 
balazs.tomasz(ohu.hypovereinsbank.com 
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A hálózati forgalom elemzése — 1. rész, 
elméleti alapok 
Ha minden Active Directory probléma megoldá- 
sát a DNS-ben kell keresni, akkor ugyancsak 
ökölszabály alapján minden, elsőre zavaros 
hálózati hiba felderítésekor a Network Moni- 
tort KELL használni. Mondogatom ezt már jó 
ideje mindenféle fórumon, de úgy vettem észre, 
nem átütő sikerrel. Vannak, akik fel sem telepítik, 
s vannak, akik az első elkapott hálózati forgalom 
megtekintésekor borzadnak el, s hiszik, hogy itt a tudomány 
és a fantasztikum számukra soha meg nem világosodó keve- 
rékéről van szó - pedig dehogy. Kedves Olvasóim bizony 
megtanulták, és sikeresen le is vizsgáztak anno a hálózati 
architektúrák témaköréből: ez volt az OSI modell. 
A sikeres vizsgához néhányan versike formájában be is 
magolták, hogy: 
n Physical, Datalink, Network, Transport, Session, Presentati- 
on, Application" 
ami magyarul így hangzik: 
Minden vízbe mártott test..." ja nem, ez egy másik versike :) 
Csak hát az elmúlt X évben gyakorlatilag egyetlen esetben 
sem vették hasznát e tudásnak, s így az szép lassan elkopott. 
Határozottan kijelenthetem azonban, hogy nem tekinthető 
komoly szakembernek az, aki nem képes olvasni az Ethernet 
csomagokban. Napjaink hálózati operációs rendszerei és az 
arra épülő komplex alkalmazások kommunikációja bizony né- 
ha olyan pofonegyszerű beállítási (vagy tervezési) hibán mú- 
lik, hogy utólag a fejünket verjük a falba, hogyan is nem vet- 
tük észre azonnal, hogyan is lehettünk annyira vakok! 
A látáshoz azonban eszköz is kell. A hálózati forgalom nyers 
adatainak megtekintésére úgynevezett sniffert használunk 
(sniff-szimatol) , mellyel az Ethernet (Token Ring stb.) háló- 
zati forgalom bitszintű elemzésére is lehetőség nyílik. Snif- 
ferből van buta és okos, drága és olcsó, de érdekes módon 
az egyik legokosabb ilyen szoftver ingyenes: a Windows NT 
és a Windows 2000 telepítőlemezén találjuk a Network Mo- 
nitor programot, melynek funkciókészlete a több százezer 
forintos egyedi snifferek tudásával vetekszik. A teljesség je- 
gyében mindjárt megjegyzem, hogy a NetMon két változat- 
ban áll rendelkezésünkre: a beépített ingyenesben a hacker- 
funkciók le vannak tiltva, ám a Systems Management Server 
CD-jén található NM extra a csomagkivonatolástól (coalesce) 
a csomagok átirkálásán keresztül Ethernet keretek hálózat- 


. ba pumpálásáig mindent tud: kész hackerarzenál. 


Mit is tud a NetMon? Elsősorban arra képes, hogy a hálóza- 
ti forgalmat minden adatával egyetemben elénk tárja, hogy 
abból következtetéseket vonhassunk le. Ezt a rétegzett há- 
lózati architektúra egy alacsony szintjének (NDIS, Network 
Driver Interface Specification eszközmeghajtó) megcsapolá- 
sával éri el. Mivel az NDIS meghajtó a lehető legalacso- 
nyabb szoftverréteg a hierarchiában (alatta már a hálókár- 
tya hardvere dolgozik) gyakorlatilag minden olyan bitet lát- 
tatni enged a NetMon, amit a hálózati kártya felfelé, az 
operációs rendszer felé kibocsát magából. Itt álljunk meg 
egy pillanatra. Mintha az OSI modellben nem lenne NDIS 
réteg! Nincs bizony! Az OSI modell csak egy ajánlás arra 
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nézvést, hogy hogyan kell(ENE) rétegzett hálózati architektú- 
rákat építeni, ám ezt történelmi okokból gyakorlatilag egyet- 
lenegy gyártó sem tartja be - nem is teheti, hisz az OSI mo- 
dell helyett a TCP/IP modellt követjük, mely nem szabványos 
ugyan, de mindenki azt használja, mert mindenki azt használ- 
ja. Az alábbi ábra a Windows 2000 Helpjéből származik, és tö- 
kéletesen mutatja az OSI és a TCP/IP össze (nem) függéseit. 
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Az OSI elkésett. Addig vacakoltak vele az ISO szabványügyi 
hivatalban, míg mire készen lett, a világot elborította a 
TCP/IP, amely szintén rétegzett, csak másképp, és van ve- 
le baj bőven. Itt és most nem elemezném az OSI modell ré- 
tegeit és előnyeit, elégedjünk meg azzal, ha azt mondom: 
minden, ami hiányzik a TCP/IP-ből az OSI modellre épített 
hálózatokon elérhető lenne (tömörítés, titkosítás, irányított 
csatornák) . Ne áltassuk magunkat, a TCP/IP-ben nics titko- 
sítás. Az IPsec, az SSL, a S/MIME, a PPTP, az L2TP mind- 
mind toldozgatás-foldozgatás! És nincs irányított csatorna 
sem, a WinSock és a Named Pipes - protézis, hogy szép le- 
gyen a TCP/IP mosolya. 

De térjünk vissza az NDIS-megcsapoláshoz. Ezek szerint van 
olyan adat, amit nem látunk a NetMonnal, mert a kártya 
hardverből , lekeveri"? Van bizony! Ilyen az Ethernet fejlé- 
cet megelőző, órajelszinkronizációs szerepű Preamble (8 
bájtnyi 10101010) és a bithibák kiszűrését segítő CRC kód 
a keret legvégén. Ha a CRC jó, megkapjuk a csomagot (de 
a CRC-t nem), ha pedig rossz, semmit sem kapunk! Ebből 
máris leszűrhető az a tanulság, hogy a NetMonnal a hálózat 
hardveres hibáinak megtalálására csak áttételesen, véletle- 
nül, vagy nagyfokú ravaszsággal nyílik mód, ugyanis ha a 
HW rossz - nem látunk semmit. Ez az eszköz a magasszin- 
tű szoftverek botlásainak felderítésére való, kábelhibák ki- 
mérésére hívjunk szakembert. 

A NetMonnal alapvetően kétféle hálózaton dolgozhatunk, 
pont-pont kapcsolatot megvalósító és üzenetszórásos csa- 
tornán. A pont-pont kapcsolatra a legjobb példa a kapcsolt 
telefonvonalak használata, ahol a tárcsázáskor kialakuló 
kommunikációs útvonal a későbbiekben nem változik, így 
az elküldött csomagok címzésére semmi szükség nincs, hisz 
az egyik oldalon feladott adat csakis a kábel másik végén 
pottyanhat ki. Ide sorolható az ATM is, bár ott virtuális csa- 
tornaazonosítókkal meg kell határozni, hogy melyik ,kábe- 
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len" kommunikálunk. Üzenetszórásos csatornánál azonban 
egy adott alhálózat minden gépe , hallja" az összes adást, 
maximum nem vesz róla tudomást, és nem küldi , fel" az 
operációs rendszernek. Így működik az Ethernet, a Token 
Ring és még több más, kihalt hálózati rendszer. Ezeken 
minden egyes elküldött csomag tartalmazza a feladó és a 
címzett egyedi azonosítóját, úgynevezett MAC (Media Ac- 
cess Control) címét, hogy a hálózati eszközök eldönthessék, 
vajon a beérkezett csomag nekik szól-e vagy sem. Kezdeti 
próbálkozásunk szempontjából egyelőre közömbös, hogy 
HUB vagy SWITCH köt minket össze a hálózattal, mert az 
ingyenes NetMon úgyis csak azokat a csomagokat képes 
megjeleníteni, amelyeket gépünk az Ethernet címzés miatt 
valóban megkap. (A , vájtszeműbbek" észrevehetik, hogy a fő- 
képernyőn található kijelzők a teljes hálózati forgalmat és ter- 
helést mutatják, azaz a NetMon driver valójában mégiscsak pro- 
miszkusz üzemmódba kapcsolja az Ethernet kártyát, és csak a 
felhasználói felület van lebutítva. Ugyanez igaz a NetMon által 
a rendszerbe illesztett Performance Monitor számlálóról, a "9o 
Network Segment"-ről is: minden Ethernet keretet beszámít, 
még azokat is, amelyek nem a mi gépünknek szólnak.) 
Indítsuk el a NetMont, és játszadozzunk vele egy kicsit! 
Telepítés NT4-nél Crtl Panel-sNetwork-sServices-zAdd, Net- 
work Monitor Tools and Agent (vigyázat, TOOLS és Agent, nem 
sima Agent!), Windows 2000-nél Ctrl Panel-2Add/Remove 
Software-z:Windows Components, Network 8. Monitoring Tools 
vagy ehhez hasonló név alatt. Szépen beköltözik a rendszer- 
gazda szokásos eszközei közé. Elindítás után így néz ki: 
BEEEEZEZEETTTTTKTTTZTET NET ZETTEETSETETT adülzi 
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Alapvető használata rém egyszerű, a felhasználói felület nem 
nagyban különbözik a videomagnóétól, s azt -— ugye - az 
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egész család tudja kezelni, így ezzel sem lehet gond  bára 
lejátszás" gomb éppenséggel felvesz. Próbaképpen kapjunk 
el néhány másodpercnyi hálózati forgalmat, és nézzük, hány- 
féleképpen elemezhetjük. Amíg a csomagok elkapása, gyűj- 
tése folyik, addig a főképernyőn az éppen zajló forgalom sta- 
tisztikáit láthatjuk. Mely gépek küldenek csomagot és kinek, 
milyen címzéssel (unicast, multicast, broadcast). Már itt le- 
hetőségünk van arra, hogy ha egy MAC addressről pontosan 
tudjuk, hogy melyik gépé, akkor a címen jobb gombbal kat- 
tintva átírhatjuk a megnevezést, ami a későbbiekben nagy- 
ban meg fogja könnyíteni az adatok értelmezését. 
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Ha esetleg nem tudjuk fejből a hálózat összes gépének MAC 

addressét, ne csüggedjünk: a NetMon majd azt is kideríti! 
Promiszkusz mód 

Ez a fogalom nem egy nemi eltévelyedést takar, ha- 
nem a hálózati kártyáknak egy olyan üzemmódját, 
amikor azokat a csomagokat is , felküldik" az operá- 
ciós rendszernek, amelyeket nem is az adott gépnek 
címeztek. Akkor hogy kerültek oda? Az Ethernet, a To- 
ken Ring és még sok társuk űgynevezett üzenetszórá- 
sos módon közvetítik az adatokat: mindenki hallja, de 
csak az veszi az adást, akinek szól. Olyan, mintha egy 
teremben kiabálnék valakinek: mindenki hallja, aki 
ott van, de nem vesz róla tudomást csak az, akinek 
szólok. A promiszkusz üzemmódba kapcsolt hálózati 
kártya minden egyes , meghallott" csomagot felküld 
az operációs rendszernek. 


MAC address és címzésmódok 

Minden egyes hálózati kártya rendelkezik egy - az esetek 
elsöprő többségében - gyárilag beleégetett egyedi azono- 
sítóval, a hatbájtos MAC addressel. Ez teszi lehetővé, hogy 
a használt protokolltól függetlenül megvalósítható legyen 
a gépek egyenkénti címzése. Maga a MAC address két rész- 
re bontható: 3 bájtnyi gyártóazonosítóból és 3 bájtnyi so- 
rozatszámból tevődik össze. (Például a Katron kártyák 
0040F6 gyártóazonosítóval rendelkeznek) . 

Az Etherneten három különböző címzésmód használható. 
Unicas, multicas és broadcast. A leggyakrabban használt a 
Unicast, melynél mindössze két gép kommunikál egymással, 
ilyenkor az Ethernet keret fejlécének címmezőjében a célgép 
MAC addressét találjuk. Vannak olyan forgalomtípusok, me- 
lyeknek minden gépre el kell jutniuk, ezt broadcast címzés- 
sel valósítják meg. Ilyenkor a keret fejlécében nem egy 
adott gép MAC addresse szerepel címzettként, hanem egy 
speciális jelzés: OxXFFFFFFFFFFFF. Ezt mindegyik gép magáé- 
nak érzi - a PC-től a hálózati kártyás iratmegsemmisítőig - 
és a csomagot feldolgozásra továbbadja a magasabb szintű 
rétegeknek. A harmadik és legritkábban használt címzés a 
multicast. Ilyenkor egy ,központi adó műsorsugárzására" 
kapcsolódik rá nulla, vagy több vevő olyan formán, mint 
ahogy a rádióadásokat hallgatjuk. Legelterjedtebb felhasz- 
nálási területei közé tartozik a multimédia adatok terítése 
vagy egyidejű telepítések megvalósítása (ghost).Kezdeti 
csomagelemzéseinkben a multicast nemigen fog előfordulni. 
Első kísérletünk legyen egy PING hálózati forgalmának 
elemzése. Ha tehetjük, kezdetben tiszta környezetben pró- 
bálkozzunk, ahol nincs más hálózati forgalom, mint az, 








WINDOWS 2000 / NETWORK MONITOR 1.RÉSZ 


amit mérni szeretnénk, különben azonnal a filterekkel kell 
bajlódnunk, ami nem nehéz ugyan, de mégis jobb talán, ha 
csak annyi csomagunk van, mint amennyire számítottunk. 
Indítsuk el a Network Monitort, kattintsunk kéj a gombon, 
majd pingeljünk meg egy, a belső hálózaton található gé- 
pet, ki-ki a saját hálózatán: 

PING 172.16.0.2 

Ha megérkezett a négy válasz, állítsuk meg a felvételt, és 
tekintsük meg az eredményt a ő£] (megállíta-megtekint) 
gombbal. Ha valóban csendes volt a hálózat, körülbelül ezt 
láthatjuk: 
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arget IP: 16.0.3 

ARP: Reply, Target IP: 172.1€.0.1 Target Md. 
fecho: From 172.16.00.01 To 172.16.00.02 
Tcho Peply: To 172.16.00.01 From 172.16.00.(C 
Echo: From 172.16.00.01 To 172.1 3 
Echo Reply: To 172.16.00.01 From 
Beho: From 172.16.00.01 To 17: 
Echo Reply: To 172.16.00.01 From 
feho: From 172.16.00.01 To 172.16.00.02 


Tcho Reply: To 172.16.00.01 From reza lti 
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A fenti ábra mindjárt meg is válaszolja azt a lappangó kér- 
dést, hogy a PING miért pont négy választ ad. Mert a gé- 
pünk négy kérdést küldött ki! Küldhetne többet is, keve- 
sebbet is, sőt a -t kapcsolóval végtelen számút is, a négy 
egyszerűen a Windows-ok mágikus pingszáma. Már ebben 
a listában is rendkívül sok érdekességet láthatunk, többek 
között azt, hogy legalább három protokoll suhant el a há- 
lózaton figyelő tekintetük előtt: BONE, ARP RARP és ICMP. 
De lássuk a részleteket. 

"0 A legelső oszlop az elkapott csomag sorszáma, ami 
még fontos lesz, ha szűréseket végzünk, mert a meg 
nem jelenített csomagok is megtartják sorszámukat. 

A második oszlop a felvétel megkezdésétől eltelt időt 
méri trilliszekundumban. Ez a kijelzés megváltoztatha- 
tó, lásd később! 

A harmadik és negyedik oszlop a feladó illetve a cím- 
zett hardvercímét (vagy boldogabb esetben nevét) mu- 
tatja. Ha nincs meg a név, kísérletezhetünk a Display- 
5Find All Names menüponttal, hogy megfejti-e a kis- 
okos a többi gép nevét. Ha nem, akkor még mindig ott 
a jobbklatty... 

Az ötödik oszlop a legmagasabb értelmezett protoll ne- 
vét tartalmazza. Hangsúlyos, hogy LEGMAGASABB, 
meg hogy ÉRTELMEZETT, mert először is a NetMon alap- 
értelmezésben nem értelmez minden protokollt (pél- 
dául a Kerberost sem, de felokosítható), másodszor, ha 
nem értelmez egy magasszintű protokollt, akkor a lis- 
tában az eggyel alatta lévő réteget jelenítni meg, Ker- 
beros esetén például annyit, hogy TCP-ről van szó - a 
többi számára is rejtély. A legmagasabb pedig azt je- 
lenti, hogy ha ott ICMP-t olvasunk, akkor is gondol- 
junk arra, hogy az ICMP-t IP cipeli a hátán, az meg 
Ethernet keretben utazik. 

Ha kibontjuk a csomagot, ez azonnal ki is derül, duplaklatty 
az egyik soron: 
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Roppant zavaros, egyelőre ne ezen erőlködjünk, hanem néz- 
zük a hatodik oszlopot: ez a LEGMAGASABB, ÉRTELMEZETT 
protokoll LÉNYEGÉT tartalmazza. Ping esetében ez nem túl in- 
formatív, de http-nél nagyon megkönnyíti az olvasást, hogy 
azonnal látszik a http kérés típusa (GET, POST stb.) Most vizs- 
gáljuk meg a három elkapott protokoll szerepét a hálózatban! 
BONE 

Ezt a protokollt hiába keressük a szabványok lapjai között. 
Nem szabványos, hanem Microsoftos, és maga a Network 
Monitor bocsátja ki - tehát jelen esetben önmagunk háló- 
zati forgalmának voltunk szemtanúi. Szerepe abban kere- 
sendő, hogy mivel a NetMon igen erőteljes eszköz még így, 
read only üzemmódban is (hisz komplett Excelfájlok átkül- 
dése is elkapható vele, s abban mondjuk kollegáink fizetése 
olvasható) jogos az igény, hogy mi megállapíthassuk ami- 
kor más NetMonozik. Tekintettel arra a szomorú tényre, 
hogy a távoli hálózati kártyákat nem lehet lekérdezni, 
hogy promiszkusz módban vannak-e éppen, más módszert 
eszeltek ki Redmondban - no ez a BONE, amit minden elin- 
dított NetMon minden tizedik másodpercben kibocsát, így 
jelzi a monitorozást a többieknek. Ha a NetMon bocsátja 
ki, vajon ki olvassa? Úgy van, a NetMon! A Tools-eIdenti- 
fy NetMon Users menüpont azért tudja megmondani, hogy 
kik sniffelnek még rajtunk kívül, mert összegyűjtögeti a 
csontokat (BONE-csont) a hálózatról. Ha nincs meg a me- 
nüpont, az azért van, mert csak a NetMon főablakában je- 
lenik meg! Váltsunk át a legelső ablakra a Window menü- 
ben, és mindjárt lesz Identify menüpont. Csendes környe- 
zetben ez valahogy így néz ki: 


identify Network Monitor Users 





Total Running: 0 Total Capturing: 1 


[Adapler Address TVersion] 
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TT Add Names to Address Database 
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2 Windows 2000 


ARP RARP 

A következő protokoll az ARP RARP. Ez már szabványos, sőt, 
létfontosságú! E nélkül nem létezne unicast címzés! 

Miért? 

Ha mi pingelünk egy gépet, elvárjuk, hogy az, és csak az 
válaszoljon a kérésünkre, annak ellenére, hogy - üzenet- 
szórásos csatornáról lévén szó - a csomag Ethernet szinten 
mindenhova eljut (a switcheket megint felejtsük el). Ez 
csak úgy lehetséges, ha a MAC address helyesen van kitölt- 
ve a PING fejlécében. Igen ám, de mi azt írtuk, hogy 
PING 172.16.0.1 

...és nem azt, hogy 

PING 00-20-18-A1-B9-D2 

Pedig ez utóbbi sokkal jobban megjegyezhető. Ki ne tud- 
ná fejből a vállalat összes hálókártyájának MAC addressét? 
(Én :-) Gondoljuk végig: mi IP címmel pingelünk, de ezt 
egyik gép hálózati kártyája sem fogja felismerni, mert az 
IP cím az operációs rendszer tudománya (Windowséknál a 
registryben van, míg hálózati nyomtatók esetében az adott 
eszköz ,operációs rendszerében") Ebből az következne, 
hogy gépünk képtelen helyes MAC Adressel kibocsátani a 
pinget, hisz fogalma sincs a szomszéd masina hardverci- 
méről. Akkor? Akkor marad(na) a broadcast, hisz kezdet- 
ben kizárólag a közismert OxFFFFFFFFFFFF cím áll rendelke- 
zésre. De gondoljuk végig, micsoda erőforráspazarlás len- 
ne, ha minden gép megkapná és feldolgozná pingünket, 
majd (egy kivételével) nem válaszolna, hisz egy magasabb 
rétegben végül is kiderül, hogy a csomag nem neki szól! A 
megoldás kulcsa az ARP, azaz Address Resolution Protocol. 
Kezdetben, rendszerindítás után valóban kizárólag a bro- 
adcast hardvercímről van tudomása minden egyes gépnek. 
Ha unicast hálózati forgalomra van szükség, be kell szerez- 
nie a partner MAC addressét, aminek lekéréséhez broadcast 
csomagot fog küldeni, valahogy így: 


— Fiúklányok! Melyikőtöknek az IP címe a 172.16.0.3? 


Ezt minden gép meghallja, a hálókártyák megszakítást kelte- 
nek az oprendszer felé, amely felemeli a csomagot, belenéz, és 
ha magára ismer - válaszol. Visszaküldi a saját MAC addressét. 
A kérdező pedig feljegyzi a válaszoló hardvercímét az úgyne- 
vezett ARP gyorsítótárba. Ennek kilistázása parancssorból: 
ARP -a 

S már jöhet is a ping, vagy bármi más unicast hálózati for- 
galom. Ha a történetbe belekeverjük azt a szomorú tényt is, 
hogy az IP címek idővel megváltozhatnak (például DHCP cím- 
kiosztás miatt), akkor beláthatjuk, hogy egy masinának nem 
célszerű az idők végezetéig megjegyezni a többiek MAC add- 
ressét: a nem használt hardvercímek , élete" két perc, de még 
a használtak is csak tíz percig érvényesek, utána a szabvány 
szerint újra kell kérni őket. Egyszóval ARP RARP-pal elég 
gyakran találkozhatunk hálózati forgalom elemzése közben. 
ICMP 

A fantasztikus Internet Control Message Protocol rengeteg 
funkciót lát el, ezek közül csak egy az ICMP Echo, azaz a 
PING. Egy későbbi számban terveink szerint megjelentet- 
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jük az ICMP RFC fordítását mindannyiunk épülésére-szépü- 

lésére. A segédprotokoll Echo--Echo reply változata az IP 

kapcsolat helyességének ellenőrzésére való. Ezt most ne 
részletezzük, a PING parancsnak ezer kapcsolója van. Ét- 
vágygerjesztésként íme még néhány ICMP változat: 

"0 Redirect: routerek küldik ezt megtévelyedett munkaál- 
lomásoknak, akik rossz kapun (gateway) akarnak kijut- 
ni az alhálóról. A Redirect-et a Windows NT 4 SP3 óta 
figyelembe veszik a MS operációs rendszerei, és szót 
fogadnak a routernek. 

-b Time Exceeded: az idő lejárt. Az elküldött IP csomag 
TTL-je nullára csökkent. Ezt az üzenetet az a router 
küldi vissza, akinél a csomag élete lejár, , meghal". 

b Source Ouench: a fuldokló router így közli a túlterhe- 
lést okozó munkaállomással, hogy lassítson, mert kép- 
telen átvinni a megadott ütemben a csomagokat - a 
munkaállomás vagy figyelembe veszi, vagy nem. NT4 
óta figyelembe vesszük. Hogy a Windows ME figyelem- 
be veszi-e? Fogalmam sincs. 


Látványosságok 

S most lássuk, hogy mi mindent lehet tenni a látványosság 
fokozása érdekében. Nem öncélú színezgetésre gondolok, 
hanem arra az esetre, ha egy hosszabb , beszélgetésből" ki 
szeretnénk emelni mondjuk az SMTP forgalmat. Térjünk 
vissza a szemüveg gombbal a részletes nézetre, és színez- 
zünk! Display-sColors 






CZEECEZTTZTEZESNNT ETETETT ze 
Colors 
Foreground 
jáppleT alk Data Stream Protocol ERMEEEZEEZI 7 
jAppleT alk File Protocol -— 
IP Authentication Header (AH) Background 












intemets ARP/RARP (Address Resolu . 
jAppleT alk Session Protocol ei 
JATM Arp Protocol 

jAppleT alk Transaction Protocol 
BloodhoundOriented Netvsotk Enlity (B 
Network Monitors BOOKMARK Protoct 
BPDU (Bridge Protocol Data Unit) 

MS Browser Clear All 
CBCP (Callback Control Protocol) ű 
CCP (Compression Control Protocol) 
Coalesce Expert Trace 









Szerintem önmagáért beszél a felhasználói felület. Keres- 
sük ki az ICMP protokolllt e végtelen listából, és állítsuk át 
zöld alapon sárgára. Ne kíméljük az ARP RARP-ot sem, le- 
gyen rózsaszín alapon világoskék! Ugye fáj? Kétszínű kiad- 
vány lévén itt és most nem tudom bemutatni színhelyesen 
a látványt, így mindenképpen házi feladat a színezgetés. 
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Másik hasznos lehetőség a kijelzésmód megváltoztatása 
oly módon, hogy a listában ne a felvétel eleje óta eltelt 
másodpercek látszódjanak, hanem például a csomagok kö- 
vetési sebessége, vagy az elkapás ideje óra-percben. Ehhez 
menjünk a Display-zOptions menüpontra: 


Display Options ; 





2d 








€ Last protocol in frame. 
! 6 Auto (Based on protocols in display fiter) 
li 


Cancel úaszől 





Hexa 
Itt az ideje, hogy elmerüljünk a részletekben. Kettő katti a 
legelső ARP soron: 


ETZTETENTETEE TETTEKET EZÉSE TTL DI 
Jő Be Edt Display Iools Options Window Help 812] 


éla] : mit] SI EB 2] elt] vie] als] al 2] 

Se HAC Adar [Dsc HAC Adar] Prorocol [ Dezcriprion 2] 
0-581ZB4 LOCAL 030000000002 Bone — Security Check (0303) 
1.752299 LOCAL TOROADCAST — ARPORARP ARPI Reguest, Target 
23 Al9szz92 — 00AOCCCOTL18 LOCAL AASZRARP APP: Reply, Target IP 


all 
















förrame: Base frame properties 

ERTHERNET: ETVPE — 020806 : Protocol s ARP: Address kezolutíon Protocol 

o FTTZTYTETTEETTTZET BET ZETTIZITTTT] 

ÖRTHERNET: Source address : OOZOLSALB9DZ 

ETHERNET: Frame Length : 42 (Ox002A) 7 

ETHERNET: Zthernet Type : 0x0006 (ARP: Addrezz Resolution Protocol) é 
28 (nennirs s 

. 













RTHRONRT- Reherner Dana: Minher of data huroz ranainéne e 


bo 





70 18 Al B3 DZ 08 06 00 01 


0000010 09 00 06 04 00 01 00 20 18 AL P3 DZ AC 10 00 01 241. 
0000020 00 00 00 00 00 00 AC 10 00 02 a. 
Frame destination address Fe: 312 





Látható, hogy Ethernet keretben utazik az ARP, s az Ether- 
netet kinyitva ráálltam a Destination Address sorra, ami- 
nek tartalma hexa OxFFFFFFFFFFF. Felismerjük? Az első ARP 
kérés broadcast! Vajon ki a feladó? 


ETHERNET: Source address : OOZOI1IBAIB9D2 


Ahogy a középső ablakon kattintgatunk, az alsó, hexadeci- 
mális panelen mindig kijelölődik az a rész, aminek az értel- 
mezett változatát éppen megsimogatjuk az egerünkkel. Így 
látszik, hogy a keret legelső 6 bájtja alkotja a címzett hard- 
vercímét, a második 6 bájt a feladó címe és így tovább. Ha 
azonban rákattintunk a Frame Lenght mezőre, a hexa pane- 
len nem jelölődik ki semmi! Ennek oka, hogy a NetMon né- 
ha olyanokat is mutat, ami nincs is bent a keretben: ez egy 
számított mező! A 13.-14. bájt az úgynevezett kerettípus 
(frame type) melynek aktuális értéke (0x0806) ARP-t jelent 
(IP eseténe ez a mező 0x0800 lenne). 

És végül minden rétegben megtalálható a , Number of data 
bytes remaining", azaz az adott réteg számára egyszerűen 
cipelendő, de nem értelmezendő adattömb. Ha ARP-ot ci- 
pel az Ethernet keret, akkor ez további 28 bájt. Ezzel 
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visszaérkeztünk a rétegzett hálózati architektúrához, s jó 
alkalom kínálkozik az egymásba ágyazás ábrázolására. Min- 
den magasabb réteg az alatta lévővel szabványos interfé- 
szen át kommunikál. Ahogy az adatok egyre lejjebb jutnak 
a protokollveremben, úgy rakódik rájuk egyre több informá- 
ció, amit a NetMon meg is mutat nekünk. Az IP réteg IP fej- 
lécet tesz hozzá, az Ethernet keretez, a TCP szekvenciaszá- 
mokkal operál stb. Erre még részletesen visszatérünk. Az 
alábbi ábrán egy fiktív, tehát sem TCP/IP, sem OSI modellt 
láthatunk, ahonnan leolvasható, hogy az egyes rétegek el- 
küldés előtt hogyan egészítik ki az adatot saját fejléceikkel, 
s fogadáskor hogyan értelmezik és bontják le azt. 


Ha most egy ICMP csomagot vizsgálunk meg ebből a szem- 
pontból akkor az egyes rétegekben jól látszik, hogy men- 
nyi ott a , Number of data bytes remaining": 


4 1.752293 LOCAL OOAOCCCOT118 ICMP Echo: From 
172.16.00.01 To 172.16.00.03 PLATAN 172.16.0.3 
IP 

Frame: Base frame properties 


Frame: Frame data: 
Number of data bytes remaining -— 74 (0x004A) 


ETHERNET: ETYPE - 0x0800 : Protocol — IP: DOD 
Internet Protocol 


ETHERNET: Ethernet Data: 
Number of data bytes remaining -— 60 (0x003C) 


IP: ID - OxE45A; Proto - ICMP; Len: 60 


IP: Data: 
Number of data bytes remaining -— 40 (0x0028) 


ICMP: Echo: From 172.16.00.01 To 172.16.00.03 


ICMP: Data: 
Number of data bytes remaining — 32 (0x0020) 


Általában minden protokoll valamilyen hasznos adatot ci- 
pel, így a PING is. Nála ez 32 bájtnyi ,remaining". Házi 
feladatként mindenki vizsgálja meg, hogy mi a PING által 
átvitt ,hasznos" adat! 

Sok sikert! 


Fóti Marcell 
MCSE, MCT, MCDBA 
Folytatjuk... 
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Post Office Protocol - Version 


(RFC 1939 - részletek) ]J 

Network Working Group 

Reguest for Comments: 1939 

J. Myers, Carnegie Mellon, M. Rose 
Dover Beach Consulting, Inc., May 1996 


A Post Office Protocol 3-as verziója (POP3) segítségével az 
ügyfelek hozzáférhetnek a kiszolgálón tárolt postaládájukhoz. 
A POP3-at nem arra tervezték, hogy teljes körű levélkezelést 
nyújtson - gyakorlatilag csak a levelek letöltéséhez és tör- 
léséhez használható. Az ennél több szolgáltatást nyújtó, 
fejlettebb protokollt, az IMAP4á-et az RFC 1730 tárgyalja. 


Működés 

A kiszolgáló elindítja a POP3 szolgáltatást, amely a 110-es TCP 
porton várja az ügyfeleket. Amikor létrejön a kapcsolat, a kiszol- 
gáló először üdvözlő szöveget küld. Ezután a kapcsolat befeje- 
zéséig parancsokkal és válaszokkal kommunikálnak egymással. 
A POP3 parancsok kulcsszavakból és azok esetleges paramé- 
tereiből állnak, ezeket kis- és nagybetűvel egyaránt írhat- 
juk. A parancsok végét CRLF-fel jelezzük. A kulcsszavak és 
a paraméterek nyomtatható ASCII karaktereket tartalmaz- 
hatnak. A kulcsszavakat és a paramétereket 1-1 szóközzel 
választjuk el egymástól. A kulcsszavak 3 vagy 4 karakter 
hosszúak. A paraméterek akár 40 karakterből is állhatnak. 
A parancsokra adott válaszok egy állapotjelzőből és egy 
kulcsszóból állnak, melyeket további információ is követhet. 
A válaszok végét CRLF-fel jelezzük. A válaszok 512 karakter 
hosszúak lehetnek, beleértve a záró CRLF-et is. Jelenleg 2 ál- 
lapotjelző van: pozitív (,-4OK") és negatív (,,-ERR"). A kiszol- 
gálónak ezeket (,,--OK" és ,,-ERR") nagybetűsen kell küldenie. 
Bizonyos parancsokra többsoros válasz adható. Ezekben az 
esetekben, melyeket később részletesen is tárgyalunk, a 
válasz minden sorát CRLF-fel zárjuk, majd utolsóként egy 
olyan sort küldünk, amely csak egy pontot (ASCII kódja 
46) és CRLF-et tartalmaz. Ha a többsoros válasz valamelyik 
sora ponttal kezdődik, akkor a kiszolgáló a sor elejére még 
egy pontot tesz. A többsoros válasznak ezzel az 5 oktettel 
kell végződnie: ,CRLF.CRLF". Többsoros válasz értelmezé- 
sekor az ügyfél először megnézi, hogy az adott sor ponttal 
kezdődik-e. Ha igen, és ezt a pontot nem CRLF követi, ak- 
kor ez a sor eleji pont eldobásra kerül. Ha pedig a sor ele- 
ji pontot CRLF követi, akkor az a többsoros üzenet végét 
jelzi, és az egész sor eldobódik. 

Egy POP3 folyamat több szakaszból áll. Amikor létrejön a 
TCP kapcsolat, és a kiszolgáló elküldi üdvözletét, megkez- 
dődik az AUTHORIZATION (hitelesítési) szakasz. Ebben a 
szakaszban az ügyfélnek azonosítania kell magát a kiszol- 
gáló számára. Ha ez sikeres, a kiszolgáló megnyitja az ügy- 
fél postaládáját és innentől kezdve a TRANSACTION (lebo- 
nyolítási) szakaszról beszélünk. Ebben a szakaszban az 
ügyfél kéréseket küld a kiszolgálónak. Amikor kiadja a 0U- 
IT parancsot, a folyamat az UPDATE szakaszba lép. Ebben a 
kiszolgáló felszabadítja a tranzakciós szakaszban lefoglalt 
erőforrásokat és elköszön, majd bezárja a TCP kapcsolatot. 
Az ismeretlen, nem megvalósított vagy szintaktikailag hi- 
bás parancsokra a kiszolgálónak negatív állapotjelzővel 





KELL válaszolnia. Akkor is így kell tennie, ha egy 
parancsot nem a megfelelő szakaszban kap. Te- 
kintve, hogy csak egyfajta , negatív" állapotjel- 

ző van, az ügyfél nem tudja eldönteni, hogy 
esetleges opcionális parancsát a szerver nem 
ismeri, vagy nem akarja/tudja végrehajtani. 

A POP3 kiszolgálónak lehet időzítője, amely az 
inaktív ügyfeleket leválasztja. Az időzítés ne le- 
gyen rövidebb 10 percnél. Az ügyféltől érkező bár- 
milyen parancs újraindítja az időzítőt. Ha az időzítő 
lejárna, a folyamat nem lép az UPDATE szakaszba - a kiszol- 
gáló lezárja a TCP kapcsolatot az ügyfél értesítése nélkül. 





Az AUTHORIZATION szakasz 

A TCP kapcsolat létrejöttekor a kiszolgáló egy rövid, egy- 
soros üdvözletet küld az ügyfélnek. Ez lehet bármilyen po- 
zitív ( azaz , 40K" -val kezdődő) válasz, például: 

4OK POP3 server ready 

A POP3 folyamat most az AUTHORIZATION szakaszban van. 
Az ügyfélnek azonosítania és hitelesítenie kell magát a ki- 
szolgáló előtt. Két módon teheti ezt meg, a USER/PASS pa- 
rancsokkal, vagy az APOP paranccsal. További hitelesítési 
módokat az 1734-as számú RFC-ben találunk. (Az Exchan- 
ge Server az APOP parancsot nem, viszont az RFC1734-ben 
definiált AUTH parancsot és rajta keresztül az NTLM azono- 
sítást támogatja - a lektor) 

Az ügyfél eredményes hitelesítése után a kiszolgáló zárol- 
ja a postaládát, megakadályozandó a levelek esetleges mó- 
dosítását vagy törlését, még mielőtt a folyamat az UPDA- 
TE szakaszba lépne. Ha sikerül a zárolás, pozitív állapotjel- 
zőt küld az ügyfélnek. A folyamat ezzel a TRANSACTION 
szakaszba lép. Ha a postaládát nem sikerül megnyitnia 
(például nem tudja zárolni, az ügyfélnek nincs jogosultsága 
a postaládához, vagy a leveleket nem tudja olvasni), akkor 
negatív állapotjelzőt küld. (Amennyiben a zárolás már sike- 
rült, de valami okból mégis el kell utasítania a parancsot, a 
kiszolgálónak még a negatív állapotjelző küldése előtt fel 
kell oldania a postaláda zárolását.) A negatív visszajelzés 
után a kiszolgáló bonthatja a kapcsolatot. Ha nem teszi, 
az ügyfél próbálkozhat újabb hitelesítési paranccsal, vagy 
jelezheti a kapcsolat végét a OUIT paranccsal. 

Miután a kiszolgáló megnyitotta a postaládát, sorszámot ren- 
del a levelekhez és feljegyzi azok méretét. Az első levél az 
1-es, a második a 2-es, az n-edik az n-edik sorszámot kapja. 
A sorszámok és a levelek méretei tízes számrendszerűek. 


A TRANSACTION szakasz 

Ha az ügyfél azonosította magát, a kiszolgáló pedig sikeresen 
zárolta és megnyitotta a postaládáját, akkor eljutottunk a le- 
bonyolítási szakaszba. Az ügyfél ebben az alábbi parancsokat 
adhatja ki, akár többször is. A kiszolgáló minden parancsra 
válaszol. Ez a szakasz az ügyfél által kiadott OUIT paranccsal 
zárul, mely után a folyamat az UPDATE szakaszba lép. 

A lebonyolítási szakaszban az alábbi parancsok adhatók: 
STAT 

A kiszolgáló válaszában pozitív állapotjelző után informá- 
ciókat közöl a postaládáról. Hogy könnyen értelmezhető le- 
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gyen, a válasz kötött formátumú: a pozitív állapotjelző 
(..40K") után 1 szóköz, az üzenetek száma, újabb szóköz, 
majd a postaláda mérete oktetben megadva. Végül a sort 
záró CRLF jön, illetve ez előtt egyes fejlettebb megvalósítá- 
sú kiszolgálók még további információkat is közölhetnek. 
Vegyük figyelembe, hogy a törlésre megjelölt üzenetek 
nem számítanak az összegzésnél! 

Példa: (ü: ügyfélgép, k: kiszolgáló): 


Ü: STAT 
K: $OK 2 320 


LIST [msg] 

Paraméter: egy levélsorszám (opcionális), amely nem lehet 
törlésre megjelölt levélé. 

Amennyiben van paraméter, (és a paraméternek megfelelő 
sorszámú levél) a kiszolgáló a megadott sorszámú levélről 
közöl információt pozitív válaszában. Nem létező sorszám 
megadása esetén a válasz negatív (,,-ERR"). 

Ha nincs paraméter, de a postaláda üres, a kiszolgáló pozitív 
állapotjelzőt, majd egy pontot és CRLF-et tartalmazó sort küld. 
Ha a postaláda tartalmaz leveleket, akkor a pozitív válasz 
több soros lesz. A bevezető --OK után a postaládában lévő 
minden egyes levélről 1 sor információt küld a kiszolgáló. 
Hogy könnyen értelmezhető legyen, a válasz kötött formá- 
tumú: a levél sorszáma után 1 szóköz, majd a levél mérete 
oktetben megadva (a levél pontos méretének kiszámítási 
módját később, ,,A levél formátuma" c. fejezetben ismertet- 
jük). Végül a sort záró CRLF jön, illetve egyes fejlettebb 
megvalósítású kiszolgálók még további információkat is 
közölhetnek ez előtt. 

Vegyük figyelembe, hogy a törlésre megjelölt üzenetek 
nem jelennek meg a listában! 

Példa: 


LIST 
4OK 2 messages (320 octets) 
1 120 
2 200 


a E B E 


zak 


LIST 2 
K: 4$OK 2 200 


Ü: LIST 3 
K: -ERR no such message, only 2 messages 
in maildrop 


RETR msg 
Paraméter: egy levélsorszám (kötelező megadni), amely 
nem lehet törlésre megjelölt levélé. 

Ha a kiszolgáló pozitív választ küld, akkor az több- 
soros lesz. A kezdő ,-OK" után a kiszolgáló elkül- 
di a kért sorszámú levelet. 

Példa: 


Ü: OUIT 


Ü: 9UIT 


Ü: RETR 1 

K: FOK 120 octets 
Kz 

Kz 

DELE msg 


Paraméter: egy levélsorszám (kötelező megadni), amely 
nem lehet törlésre megjelölt levélé. 

A POP3 kiszolgáló megjelöli a levelet, mint törlendőt. To- 
vábbi parancsokban már nem hivatkozhatunk erre a sor- 
számra, mert hibaüzenetet kapunk. A POP3 kiszolgáló 
mindaddig nem törli ténylegesen a levelet, amíg a folya- 
mat az UPDATE szakaszba nem lép. 

Példa: 


Ü: DELE 1 

K: $OK message 1 deleted ... 

Ü: DELE 2 

K: -ERR message 2 already deleted 


NOOP 

A POP3 kiszolgáló nem csinál semmit, csak küld egy pozi- 
tív választ. (Általában az időtúllépés megakadályozására 
használják — a lektor.) 

RSET 

A törlésre megjelölt levelekről eltávolítja a törlésjelzőt, 
majd a POP3 kiszolgáló küld egy pozitív választ. 

Példa: 


Ü: RSET 
K: 4$OK maildrop has 2 messages (320 octets) 


Az UPDATE szakasz 

Ha az ügyfél kiadja a OUIT parancsot a lebonyolítási sza- 
kaszban, a folyamat az UPDATE szakaszba lép. (Amennyiben 
a OUIT parancsot a hitelesítési szakaszban adja ki, a folya- 
mat megszakad anélkül, hogy az UPDATE szakaszba lépne.) 
Ha a folyamat az ügyfél által kiadott OUIT parancson kívül 
bármilyen okból megszakadna, akkor nem lép be az UPDA- 
TE szakaszba és nem törölhet egyetlen levelet sem. 

AUIT 

A POP3 kiszolgáló eltávolítja a törlésre megjelölt leveleket a 
postaládából, majd a művelet sikerességétől függően válaszol. 
Ha a törlés közben valami hiba következik be, lehetséges hogy 
a törlésre megjelölt levelek közül nem sikerül mindegyiket el- 
távolítani. Az azonban nem fordulhat elő, hogy olyan levél is 
letörlődjön, amely erre nem volt megjelölve. 

Akár sikerült a törlésre megjelölt levelek eltávolítása, akár 
nem, a kiszolgáló megszünteti a postaláda zárolását és be- 
zárja a TCP kapcsolatot. 

Példa: 


K: 4OK dewey POP3 server signing off (maildrop empty) ... 


K: $OK dewey POP3 server signing off (2 messages left) ... 
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A fenti POP3 parancsokat minden POP3 kiszolgálónak tá- 
mogatnia kell. 

Az alábbi opcionális parancsok több lehetőséget biztosíta- 
nak az ügyfél számára. 

TOP msg n 

Paraméter: egy levélsorszám (kötelező megadni), amely 
nem lehet törlésre megjelölt levélé, valamint a kért sorok 
száma (egy nem negatív szám, szintén kötelező). 

Ha a kiszolgáló pozitív választ ad, akkor az több soros lesz. A 
kezdő -OK után a kiszolgáló elküldi a levél fejlécét, a fejlécet 
a törzstől elválasztó üres sort, majd a kért számú sort a levél 
törzséből. Ha az ügyfél több sort kér, mint amennyi a levél tör- 
zsében van, akkor a kiszolgáló az egész levelet elküldi neki. 
Példa: 


Ü: TOP 1 10 

K: 4OK 

K: 

K: 

Ü: TOP 100 3 

K: -ERR no such message 


UIDL [msg] 

Paraméter: egy levélsorszám (opcionális), amely nem lehet 
törlésre megjelölt levélé. 

Amennyiben van paraméter (és a paraméternek megfelelő 
sorszámú levél), a kiszolgáló a megadott sorszámú levélről 
közöl információt pozitív válaszában. 

Ha nincs paraméter, és a kiszolgáló pozitív választ ad, akkor 
az többsoros lesz. A bevezető --OK után a postaládában lévő 
minden egyes levélről 1 sor információt küld a kiszolgáló. 
Az egyedi azonosító a kiszolgáló által képzett karaktersoro- 
zat, amely hexadecimális 21-től 7E-ig tartalmazhat karakte- 
reket, legalább 1, legfeljebb 70 darabot. Az azonosító nem 
csak egy folyamat idejéig tartozik a levélhez: ha a folyamat 
megszakadna még az UPDATE szakasz előtt és újat kezde- 
nénk, a levélnek az új folyamatban is ugyanaz lesz az azo- 
nosítója. A kiszolgáló nem adhatja ki az azonosítót újra ad- 
dig, amíg az eredetileg hozzárendelt levél létezik. 

USER name 

Paraméter: a postaláda azonosítója (kötelező megadni) 
Korlátozás: csak a hitelesítési szakaszban, közvetle- 
nül a POP3 üdvözlés, vagy egy sikertelen USER vagy 
PASS parancs után adható ki. 

A USER és PASS parancsok kombinációjával történő hitelesí- 
téshez az ügyfélnek először a USER parancsot kell kiadnia. 
Ha a kiszolgáló erre pozitív választ ad, akkor az ügyfél foly- 
tathatja a hitelesítést a PASS paranccsal, vagy a OUIT pa- 
ranccsal megszakíthatja a POP3 folyamatot. Ha a kiszolgáló 
negatív választ ad a USER parancsra, az ügyfél küldhet újabb 
hitelesítési parancsot, vagy kiadhatja a OUIT parancsot. 

A kiszolgáló akkor is adhat pozitív választ, ha a postaláda 
nem létezik. De létező postaláda esetén is adhat negatív 
választ, ha nem engedélyezi a titkosítás nélküli jelszavak- 
kal történő hitelesítést. 
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Példa: 


Se 


USER frated 

-ERR sorry, no mailbox for frated here ... 
USER mrose 

K: 4OK mrose is a real hoopy frood 


PASS string 

Paraméter: a kiszolgálón lévő postaládához tartozó jelszó 
(kötelező megadni) 

Korlátozás: csak a hitelesítési szakaszban adható ki, köz- 
vetlenül az eredményes USER parancs után. 

Amikor az ügyfél kiadja a PASS parancsot, a kiszolgáló a 
USER és a PASS parancsok paramétereinek alapján eldönti, 
hogy az ügyfél jogosult-e hozzáférni a kért postaládához. 
Mivel a PASS parancsnak csak egy paramétere van, használ- 
ható szóköz is a jelszóban, a kiszolgáló nem fogja paramé- 
ter-elválasztóként kezelni. 

Példa: 


: USER mrose 

: OK mrose is a real hoopy frood 

: PASS secret 

: -ERR maildrop already locked ... 

: USER mrose 

: OK mrose is a real hoopy frood 

: PASS secret 

: OK mrose"s maildrop has 2 messages (320 octets) 


3 GAGA GX G 


APOP name digest 

Paraméter: egy a postaládát azonosító sztring, valamint egy 
MD5 digest string (mindkettő megadása kötelező) 
Rendszerint minden POP3 folyamat USER/PASS parancsok- 
kal indul. Mivel ilyenkor a jelszavak kódolatlanul haladnak 
át a hálózaton, ez súlyos biztonsági problémát jelent. 
Ráadásul a POP3 ügyfélprogramok nagy része új leveleket 
keresve igen gyakran létesít kapcsolatot a kiszolgálóval, így 
a jelszavak lehallgatásának esélye igen magas. 

Ezért szükség van egy alternatív hitelesítési módra, amely 
nem küld kódolatlanul jelszavakat a hálózaton. Ezt a funkciót 
az APOP parancs nyújtja. (Megj.: az Exchange Server nem tá- 
mogatja az APOP parancsot, helyette használjunk teljesen tit- 
kosított (SSL) POP3 kommunikációt, vagy a cikk elején emlí- 
tett AUTH NTLM azonosítást /ld. RFC1734/. - a lektor.) 
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Biztonságos Exchange levelezés 2. rész 


A cikk előző részében a levelezés biztonsági kérdé- 
seinek alapjaival, a javasolt telepítés módszereivel 
és a titkosított levelek küldésével foglalkoztunk. 


A mostani részben az internetes levelezés és az 


Outlook Web Access biztonságáról, a mentés 
és helyreállítás problémáiról, valamint a vírus- 
védelem lehetőségeiről és az Outlook 2000 SR1 
biztonsági újdonságairól lesz szó. 


Internetes levelezés - SMTP 
Az SMTP protokoll a TCP/IP protokollcsalád internetes 

levelezést megvalósító, alkalmazásszintű tagja. Egyszerű 
szöveges parancsok segítségével működik, amelyeket akár mi 
magunk is lejátszhatunk az SMTP kiszolgálóval egy telnet ab- 
lakban. (E számunkban éppen a POP3 protokollt mutatjuk be 
a Szabványok rovatunkban, de ígérjük, rövidesen az SMTP rész- 
letes magyarázatára is sort kerítünk — a szerk.) 
A levelezőkiszolgálókban az SMTP levelezést végző szoftver- 
komponens általában egy különálló modul, amely önállóan 
tud döntéseket hozni, természetesen a levelezőkiszolgáló 
címtárinformációira alapozva. Azaz el tudja dönteni, hogy 
egy neki küldött levelet a levelezőkiszolgálónak (vagy más 
szóval üzenettárnak, ami akár lehet maga a fájlrendszer is) 
kell-e átadnia, vagy pedig továbbítania kell valamilyen má- 
sik SMTP kiszolgáló felé. Ezt hívjuk SMTP továbbításnak (re- 
lay-nek). A továbbítás az Internet hőskorában nem okozott 
senkinek sem különösebb gondot, hiszen az internetes kö- 
zösségben mindenki barátként tekintett a másikra, azaz akár 
mások leveleit is szívesen továbbította, amennyiben azok vé- 
letlenül nem a megfelelő SMTP kiszolgálóra tévedtek. Azon- 
ban manapság, az Internet üzletiesedésével sajnos már nem 
engedhetjük meg magunknak, hogy bárkinek a levelét átirá- 
nyítsuk, mert vannak rossz szándékú emberek, akik csak azért 
irányíttatják levelüket a mi kiszolgálónkkal, hogy azt leterhel- 
jék, vagy azért, mert olyan kéretlen üzleti ajánlatokkal 
(spam) akarják elárasztani a világot, amihez nem szívesen ad- 
ják a saját IP címüket. Ilyenkor ugyanis az átirányított levél 
forrása a mi SMTP kiszolgálónk lesz és kéretlen üzleti levelek 
terjesztése miatt különböző , feketelistákra" tehetik a kiszol- 
gálónkat, ami egyrészt nem túl jó reklám, másrészt nem fog- 
ják elfogadni más kiszolgálók az általunk küldött leveleket. 
Az SMTP védelem egyik fő célja tehát az, hogy ne tudja bár- 
ki szabadon átirányításra felhasználni kiszolgálónkat. Másik 
fő célja pedig, hogy leveleinket ne tudja bárki elcsípni, elol- 
vasni, módosítani útközben. 
Az első cél érdekében azt tudjuk tenni, hogy úgy konfigurál- 
juk az SMTP kiszolgálónkat, hogy csak a saját levelező rend- 
szerünkben használatos tartománynévre (a (2 utáni címrész) 
küldött leveleket fogadja, vagy esetleg olyan egyéb levelező 
tartományokét is, amelyek számára szintén mi gyűjtjük a le- 
veleket. A második cél érdekében használhatjuk a cikk előző 
részében ismertetett levéltitkosítást, vagy titkosíthatjuk ma- 
gát az SMTP kommunikációt is. Sajnos mindkét fajta titkosí- 
táshoz egymás bizonyítványainak elismerésére és közös tit- 
kosítási módszerre van szükség. A levéltitkosításnál a levele- 
ző ügyfélprogramoknak, az SMTP kommunikáció titkosításá- 
nál pedig az SMTP kiszolgálóknak kell , közös nyelvet" beszél- 
niük, hogy megérthessék egymást. Jelenleg ezeket a techno- 
lógiákat még nem alkalmazhatjuk általánosan, csak olyan 
partnerekkel, akikkel ki tudjuk alakítani a hasonló platfor- 
mot. Egy több telephelyes cég például a részlegei között zaj- 
ló belső levelezésre használhatja ezeket a módszereket. Az 
S/MIME és SSL, ASL szabványok alkalmazásának köszönhe- 


tech.net 


tően azonban már egyre szélesebb körben alkalmazhatjuk 
akár a mindennapi internetes levelezésünkben is. 


Az Internet Mail Service az Exchange 5.5-ben 

Az Exchange 5.5-ben az SMTP levelezést megvalósító kompo- 
nens az Internet Mail Service. Ezt külön szolgáltatásként te- 
lepíthetjük az Exchange kiszolgálóra. Szorosan együttműkö- 
dik az Exchange üzenettárával (Information Store), egyrészt 
az internetről érkező és az oda küldendő levelek formátum- 
konverzióját az Exchange üzenettár végzi, másrészt a levele- 
ző szerverünk felhasználójának címzett levelet is az üzenet- 
tárnak adja át. 
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Az Internet Mail Service működése 


Az Exchange 5.5 IMS komponens telepítésekor a telepítő va- 
rázsló azt kérdezi, hogy mindenki számára engedjük-e az in- 
ternetes levelek továbbítását, vagy sem. Ha azt válaszoljuk, 
hogy ,nem", akkor csak a saját levelező tartományunknak 
küldött leveleket fogadja el, az összes többit visszautasítja. 
Ez látszólag kielégíti az igényeinket, azaz így biztos senki 
sem fogja illegálisan továbbításra használni a kiszolgálónkat, 
de van ezzel egy nagyon súlyos probléma. Ugyanis ez a beál- 
lítás minden levéltovábbítást elutasít, amire viszont szük- 
ségünk lehet, ha POP3 vagy IMAP4 ügyfeleink vannak. Ezek 
a protokollok csak levél letöltésre alkalmasak, azaz egy ki- 
szolgáló valamilyen levéltárából töltik le a levelet a munka- 
állomásra. De ezek használatakor is szeretnénk levelet külde- 
ni, amire se a POP3, se az IMAP4 protokoll nem képes. Mi a 
megoldás akkor? Az, hogy SMTP-t használunk a levél küldé- 
sekor, de nem úgy, mint az SMTP kiszolgálók, azaz nem akar- 
nak minden egyes levél küldésekor a cél-SMTP kiszolgálóhoz 
csatlakozni, hanem csak annyit tesznek, hogy egy továbbí- 
tásra hajlandó SMTP kiszolgálónak átadják a leveleket, ami 
aztán a végcélhoz juttatja küldeményüket. 


A MICROSOFT MAGYARORSZÁG SZAKMAI MAGAZINJA 
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[7 Specily the hosts and cfents that can route mail when the following conditions are met—— 
! F7 Hosts and cfents that successíully authenticate I 
[7 Hosts and clients with these IP addresses 

! 


A másik beállítás mellett (Reroute incoming SMTP mail) az 
itt felsorolt levelező tartományoknak szóló leveleket fogad- 
ja el az IMS, az összes többit - alapértelmezésben - bután 
továbbküldi (relay). Ez kellemetlen, úgy tűnik távolodunk a 
céltól. Megfelelő beállítás esetén azonban kordában 
tartható, sőt már akkor hibajelzést ad, amikor a feladó még 
csak ott tart az IMS-sel történő SMTP párbeszédben, amikor 
midegen" tartománynevet ad meg címzettként. Ekkor a 
feladónak nem levél fog menni, mint az előző esetben, ha- 
nem csak egy hibajelzés, ami kevésbé terheli le a kiszolgá- 
lónkat, sőt, a rossz szándékú levél adatrésze sem éri már el 
a szervert. Lássuk a beállításokat! 


Diagnostics Logging  ]  IntemetMai ] — Diatup Connections  ]  Connections  ] 
1 Permissions ] ConnectedSites ] Address Space ] DefveryRestrictions ] 
Fiouting ] 


General 
Security 


(íg Internet Mail Service (WSHINT) 


C Donotteroute incoming SMTP mail 


(7 Rergute ncoming SMTP mai (regured for POP3/MAPA support 


OAueues 





Routing Restrictions... 
TT Instead of the table, use this custom routing program: J 





AZ Internet Mail Service útválasztó beállításai 


A ,Routing" tulajdonságlapon található , Restrictions" gomb 
megnyomására megjelenő ablakban kijelölhetjük, hogy az 
engedélyezett továbbítók kik legyenek: IP címük szerint, 
felhasználó-azonosítás alapján, vagy aszerint, hogy a több 
hálózati kártyával rendelkező Exchange kiszolgálónál melyik 
IP címre csatlakozik az ügyfélprogramot futtató munkaállo- 
más. Ezen lehetőségek megfelelő kombinációjával elérhető, 
hogy továbbítás legyen is meg nem is, belső IP címekről 
hajrá, külsőről pedig csak akkor engedélyezze a továbbítást, 
ha a felhasználó érvényes név-ijelszó párossal rendelkezik 
(successfully authenticate). Ehhez az ügyfélprogramban 
addig kell kattintgatnunk, amíg rá nem bukkanunk az SMTP 
autentikációs pipára. (Legjobb, ha az SMTP autentikációt 
SSL csatornán keresztül végezzük, hogy jelszavaink bizton- 
ságosan utazhassanak.) 









( Specily the hosts and cőents that can NEVER route mal ———— — 











IMS átirányítási megszorítások, engedélyek 


Ezek a beállítási lehetőségek csak az 1. javítócsomagtól kez- 
dődően találhatók meg az Exchange 5.5-ben, ebből is lát- 
szik, hogy a biztonság szempontjából is milyen fontos a 
legújabb javítócsomagok alkalmazása. 

Az IMS , Connections" tulajdonságlapján elvileg be lehet ál- 
lítani általános jellegű felhasználó-azonosítást, de ezzel a 
lehetőséggel mégsem élhetünk, mivel ekkor nem fog tudni 
bárki levelet küldeni számunkra, csak azok a kiszolgálók, 
akik tudják teljesíteni a követelményeket. Mi az értelme ak- 
kor ennek a beállításnak? Például az, hogy kiszolgálónkhoz 
tényleg nem csatlakozhat a világ bármely másik levelező ki- 
szolgálója, csak egy bizonyos úgynevezett ,smart host", 
amely SMTP kiszolgáló védelmi vonalként óvja a mi Exchan- 
ge gépünket az esetleges támadásoktól. Ez a kialakítás azért 
jó és biztonságos, mert ezen a ,smart host"-on nincsenek 
üzenettárak, azaz ha egy rossz szándékú behatoló mégis 
tönkreteszi vagy , feltöri" ezt, attól még a levelekhez nem 
fér hozzá. A belső Exchange kiszolgálónkat nem érheti el, 
mert az egy belső IP címen helyezkedik el, a ,smart host" 
másik hálózati kártyájára csatlakozva. 


SMTP virtuális kiszolgálók az Exchange 2000-ben 

Az Exchange 2000-ben a protokollok átköltöztek az üzenet- 
tárból (POP3 és IMAP4) és az IMS-ből (SMTP) az Internet 
Information Services komponensbe. 

A másik fő változás, hogy az Exchange 2000 rendszerek köz- 
ti kommunikáció is SMTP alapú lett (szemben az Exchange 
5.5 RPC kommunikációjával). Azaz minden Exchange 2000 
már alaphelyzetben tartalmaz SMTP kiszolgálót, amire a biz- 
tonság (SMTP átirányítás) szempontjából oda kell figyelni! 
Míg az Exchange 5.5 esetében egy számítógépen csak egy 
SMTP kiszolgálót, azaz IMS-t telepíthettünk, addig az Ex- 
change 2000 esetében tetszőleges számú úgynevezett SMTP 
virtuális kiszolgálót tudunk létrehozni. Ennek az az előnye, 
hogy amennyiben különböző beállításokat akarunk a küldők 
különböző csoportjai számára létrehozni (például az IMAP- 
ot, POP3-at használó saját munkatársaink, a kívülről nekünk 
levelet küldők számára és egy interneten elérhető másik telep- 
helyünkön található Exchange kiszolgáló számára) , akkor ezt 
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sokkal egyszerűbben megtehetjük több, a különféle bizton- 
sági igényeket kielégítő virtuális SMTP kiszolgálóval. Az Ex- 
change 5.5-nél ehhez sajnos legtöbbször újabb Exchange 
5.5 kiszolgálóra, vagy kiszolgálókra volt szükség. 
Természetesen mindazt az SMTP átirányítás-korlátozást 
használhatjuk Exchange 2000 SMTP kiszolgálók esetén, amit 
az Exchange 5.5-nél megismertünk, de ezen kívül korlátoz- 
hatjuk a továbbítható levelek címzettjeinek számát is. A ké- 
retlen e-mail hirdetések (spam) sokszor abból is felismerhe- 
tők, hogy a címzett mező rengeteg címzettet tartalmaz. 

De térjünk vissza egy pillanatra ahhoz a tényhez, hogy az 
Exchange 2000 esetében minden kiszolgálón ott van az 
SMTP felület! Nem jelent-e ez vajon fokozott biztonsági ve- 
szélyt? De igen, főleg akkor, ha minden kiszolgálónknak van 
olyan IP címe, ami az internet felől megcímezhető. Ezért le- 
hetőleg ne használjunk külső IP címet az összes Exchange 
kiszolgálónkon, hanem csak azon az egy-kettőn, amellyel 
ténylegesen a külső levelezésünket le akarjuk bonyolítani. 
A bejövő leveleket így a külső címmel rendelkező kiszolgá- 
lókra tereltük, de hogyan tudjuk a kimenő leveleinket is er- 
re az egy-két kiszolgálóra terelni? Erre való az SMTP Connec- 
tor, ami az SMTP virtuális szerverek felett logikai réteget ké- 
pez, és az útválasztási algoritmusukat tudjuk módosítani se- 
gítségükkel. Alaphelyzetben minden SMTP virtuális kiszolgá- 
ló a DNS rendszer MX bejegyzései segítségével találja meg a 
cél SMTP kiszolgálót, de egy SMTP Connector esetében kije- 
lölhetünk egy úgynevezett hídfő-kiszolgálót (bridgehead 
server), ahova az összes kiszolgálónk továbbítani fogja az 
internetre küldendő leveleket, és nem maguk fogják azokat 
közvetlenül elküldeni. Ha a bejövő leveleket is ezek a hídfő- 
kiszolgálók fogadják, akkor elég ezeknek aB kívülről címez- 
hető IP címet adni, és csak ezeket kell az esetleges kívülről 
jövő támadásoktól fokozottan védeni. Ha a hídfő-kiszolgá- 
lónkon nem tárolunk semmilyen felhasználói postafiókot, 
akkor ezzel meg is valósítjuk a , smart host" szerepű kiszol- 
gálót. 


Internetes levelezés - Outlook Web Access 

Ha a világban utazgatunk és éppen nem viszünk magunkkal 
laptopot, akkor is szeretnénk az e-mailjeinket megnézni és 
leveleket küldeni. Ha máshol nem, de internet kávézókban 
szinte bárhol hozzáférünk az Internethez és egy böngésző- 
höz. Levelező programhoz már nem biztos, vagy ha mégis, 
akkor ezeknek beállítása némi időt és hozzáértést igényel. A 
legkényelmesebb az lenne, ha a böngészőnkön keresztül, 
mint egy weboldalt tudnánk letölteni a levelesládánk tartal- 
mát. Erre szolgál az Exchange kiszolgálók Outlook Web Ac- 
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Outlook Web Access felület Exchange 2000-ről 

Az Exchange 5.5-ben az OWA komponenst egy Internet In- 
formation Servert futtató gépre kell telepíteni, amely a bön- 
gésző felé dinamikus webtartalmat szolgáltat, ami az adato- 
kat MAPI kapcsolaton keresztül, az Outlookhoz hasonló 
módszerrel éri el az Exchange 5.5 kiszolgálón. 

Az Exchange 2000 esetében szinte az összes internetes pro- 
tokollt az IIS-be integrálták, így természetesen a közvetlen 
HTTP felület is minden további nélkül elérhető. 

Milyen biztonsági vonzata van a webes felületen történő le- 
velezésnek? Mindenekelőtt az, hogy legáltalánosabban az 
úgynevezett egyszerű (basic, nyílt jelszavas) felhasználó-azo- 
nosítást használjuk a webkiszolgálók elérésekor, hiszen nem 
lehetünk biztosak abban, hogy a fejlettebb azonosítási mód- 
szereket minden böngésző ismeri. A nyílt jelszavas bejelent- 
kezés során azonban a hálózati forgalom figyelésével könnyen 
kideríthetők a felhasználónevekhez tartozó jelszavak, ennek 
birtokában pedig természetesen illetéktelenek is elérhetik a 
leveleinket, súlyosabb esetben akár egyéb adatokat is. 





A védekezési módszer itt is az, hogy az ügyfélprogram és a 
kiszolgáló közti kommunikációt a Secure Sockets Layer (SSL) 
réteg alkalmazásával titkosítjuk. Ekkor a kapcsolatfelvételtől 
kezdődően nem csak a felhasználóazonosítás, hanem a bön- 
gésző felé küldött levelek szövegei, sőt, a teljes kommuniká- 
ció titkosított, így rögtön két legyet ütünk egy csapásra. 


(Meg egy harmadikat is. Nemrégiben ütköztem abba a prob- 
lémába, hogy az új OWA ugyan a 80-as portról tölti le a le- 
velek tartalmát, de WebDAV-ot használ, ami a HTTP proto- 
koll legújabb verziója. Olyan tűzfalakon nem lehet teljeskö- 
rűen ,átowázni", amelyek csak a HTTP 1.1-et engedik át. Ez 
ma már kevés! Ilyenkor csak az OWA kerete jelenik meg 
(mert az még sima HTTP-vel jön le), de a levelesláda üres 
marad. Az SSL ezen is segít: minden levél az SSL csatorná- 
ban jut el hozzám, a tűzfal kotnyeleskedése kizárt!) 


Ahhoz, hogy a webkiszolgálónk SSL rétegen keresztül tudjon 
kommunikálni, kulcspárral és bizonyítvánnyal kell ellátni. A 
cikk előző részében említettem, hogy ha az Exchange 5.5-nél 
alkalmazzuk a Key Management Servert az X509.3 szabványú 
titkosításhoz, akkor a Certificate Serverünket , el kell ronta- 
nunk" egy speciális biztonsági modullal; az IIS-ünknek ezzel 
a Certificate Serverrel ezután már nem fogunk tudni bizonyít- 
ványt adni. Azaz telepítenünk kell egy másikat valahova. Az 
Exchange 2000-nél ilyen problémánk nem lesz. 

Az SSL titkosítás viszonylag processzorigényes feladat, ezért 
jól kell kialakítani azt az Exchange kiszolgálót, amely az 
üzenettár-adatbázisok kezelése mellett ilyenkor még inten- 
zíven foglalkozik SSL titkosítással. Az Exchange 2000 eseté- 
ben segítségünkre lehet ebben egy speciális lehetőség, 
hogy egy újabb Exchange 2000 kiszolgálót teszünk a háló- 
zatba, amit úgynevezett , front-end" kiszolgálóvá alakítunk. 
Ez egyrészt csak az ügyfélprotokollokkal foglalkozik, üzenet- 
tárakkal nem, így több ideje marad az SSL titkosítások el- 
végzésére, másrészt pedig ez lehet a ,támadási felülete" a 
teljes hálózatunknak, azaz SMTP szempontjából is ez lehet a 
front-end kiszolgálónk, a ,smart host". 


Vírusvédelem 

A biztonság egyik legkritikusabb pontja a vírusvédelem. A ví- 
rusoknak nagyon sok fajtája van, és ezek különböző problé- 
mákat okozhatnak. Az egyik nagy csoport egyszerűen tönkre- 
teszi az adatokat, programokat, ami talán a kisebbik baj, ab- 
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ban az esetben, ha rendszeresen végzünk adatainkról menté- 
seket. A nagyobb baj az, hogy egy vírus telepíthet a rendsze- 
rünkre olyan programokat, amelyek például jelszavakat külde- 
nek a hálózatunkból valamilyen külső gépnek, vagy bármilyen 
egyéb módszerrel hátsó ajtót nyithat a rendszerünkben, amin 
keresztül a vírus küldője egyszerűen ki-be járhat, és illetékte- 
lenül adatokhoz férhet hozzá, vagy egyéb károkat okozhat. 
Az Exchange rendszerhez a telepítőkészletben nincsen vírus- 
védelmi lehetőség, ilyen megoldásokat egyéb gyártók kínál- 
nak. Sajnos az Exchange 5.5-ben a hármas javítócsomag 
előtt nem nagyon volt olyan programozói felület, amire ala- 
pozva hatékony vírusvédelmi megoldást tudtak volna fej- 
leszteni, ezért az ezelőtt született programok nem túl haté- 
konyak. Az SP3 egy olyan antivírus API-t (VAPI) hozott be 
a rendszerbe, amihez hatékony vírusvédelmi alkalmazásokat 
lehet fejleszteni, így érdemes vírusvédelmi megoldás kivá- 
lasztásánál ennek utánanézni, és olyan terméket választani, 
ami már ezt az API-t használja. 


Az Outlook 2000 SR1 újdonságai 

Emlékezzünk vissza a LOVE LETTER (szerelem-) vírusra! Ennek 
kapcsán megtapasztalhattuk, hogy milyen leleményesek a 
vírusíró emberek, és milyen jóhiszeműek az alkalmazói 
szoftverek készítői. A vírustámadás kapcsán a túl sok és sza- 
badon hozzáférhető funkcióval bíró Outlook levelezőprog- 
ramhoz kiadtak több javítócsomagot, amelyeket egy SR-1a 
javítócsomagban összesítettek, de azóta is jelennek meg 
újabb javítások. Nézzük meg, hogy milyen újdonságokat 
hordoznak ezek a frissítések. 

Az újdonságok első köre az S/MIME titkosításhoz tartozik, 
de ezek a funkciók rejtve maradnak, egészen addig, míg egy 
speciális registry kulcsot fel nem veszünk és abba a megfe- 
lelő értéket be nem írjuk: 


HKEY LOCAL MACHINEYSoftwarelMicrosoftNt 
officel9.OYloutlook lSecurityt 
EnableSRFeatures - 1 (REG DWORD) 


Ennek hatására számos S/MIME újdonsággal fogunk talál- 
kozni. Egyrészt jóval egyszerűbb lesz a titkosított levelek 
küldése még Key Management Server alkalmazása nélkül is, 
mert a Tools/Options/Security lapon már alaphelyzetben ki- 
választhatók a titkosítással kapcsolatos beállítások. 
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Preferences ] Mai Services ] Mai Format ] Speling Security ] other ] Delegates [ 


Secure e-mail 
an TT Enaystzon tachments for outaoina messages 
TT Add digital signature to outgoing messages 
[7 Send clear text signed message when sending signed messages 
TT Reguest secure receipt for all S/MIME signed messages 


Default Setting: -] settinos... 


Secure content 


Security zones allow you to customize whether scripts and actíve 
content can be run in HTML messages, Select the Microsoft 
Internet Explorer security zone to use, 


Zone: — [d Restricted sítes I] Zone Settings... 
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Digital IDs (Certificates) 


Digital IOs or Certificates are documents that allow you to prove your 
identity in electronic transactions. 


Publish to GAL... ImportfExport, . . Get a Digital ID... 
[moz] ésa [Dawe ] 


Az Outlook SR1a és a registry módosítás utáni biztonsági 
tulajdonságlap 
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A frissítés több kényelmi szolgáltatást is nyújt, például ha 
esetleg sérült biztonsági profilunk van, vagy a bizonyítvá- 
nyunk lejárt, akkor segít ezen problémák megoldásában. 
Maga az S/MIME szabvány is fejlődik, így szükséges ezen új- 
donságok implementálása is. A legfőbb ilyen újdonság a biz- 
tonságos nyugta, ami hasonló az olvasási nyugtához, csak itt 
arról jön vissza értesítés, hogy ellenőrizték a küldött levél- 
hez csatolt elektronikus aláírást. Ez a nyugta tartalmazza az 
eredeti hash értéket, amit az Outlook összehasonlít az elkül- 
dött üzenetek mappájában található eredeti üzenetben tárolt 
hash értékkel. Ezzel mi magunk is meggyőződhetünk arról, 
hogy az üzenet nem módosult útközben. Ehhez természete- 
sen egy sokkal biztonságosabb küldő (From) mezőre van 
szükség, mert a hagyományos küldő mező semmilyen titko- 
sítás alá nincsen bevonva. Ezért az S/MIME bevezette a ,Si- 
gned by" mezőt, amit már bevontak az elektronikus aláírás 
hash algoritmusába, így azt nyomtalanul nem lehet módosí- 
tani. A biztonsági nyugta is erre a címre megy vissza. 

Az SR1a és az erre épülő biztonsági javítások több újdonsá- 
ga a vírusvédelemhez sorolható. Ilyen például az, hogy a 
végrehajtható kódot tartalmazó e-mail mellékletek vagy tel- 
jesen hozzáférhetetlenek lesznek, vagy csak lemezre mentés 
után nyithatók meg. Másik ilyen jellegű újdonság, hogy ha 
egy program a címjegyzékekhez akar hozzáférni, mint aho- 
gyan a levélben terjedő vírusok általában teszik, akkor a fel- 
használó kap egy értesítést erről és neki kell engedélyezni 
ezt a műveletet, azaz a vírus titokban nem tud terjedni 
(legalábbis a címlistán keresztül nem — a szerk.) . 


Mentés és helyreállítás 

Fontos pár szót szólni az Exchange kiszolgálók mentéséről 
és helyreállításáról. A beépített mentés funkció egyrészt 
adatbázisszintű, azaz levelesládákra nem bontható le. Más- 
részt kifejezetten az adatbázis megsérülése esetére találták 
ki, és a meghibásodás pillanatáig próbálja az adatbázist 
visszaállítani. Ezt azért fontos hangsúlyozni, mert nem al- 
kalmas véletlenül törölt elemek visszaállítására, azaz, ha a 
felhasználó, vagy valamely vírus szabályosan töröl egy leve- 
let, akkor ez a parancs bekerül az Exchange adatbázisának 
tranzakciós naplójába. Ha visszaállítunk egy régebbi adat- 
bázist, attól még a tranzakciós naplóban a törlési utasítás 
benne marad, így a régebbi adatbázis-állapot és az azóta 
született tranzakciós bejegyzések lejátszása - ami a visszaál- 
lításnál automatikusan megtörténik -eredményeként szintén 
nem lesz meg a visszaállítandó elem. Ha a tranzakciós nap- 
lót töröljük, akkor pedig az összes mentés óta keletkezett 
egyéb adat, levél veszik el. Ezért használjunk egyéb archivá- 
lási lehetőségeket, amelyek lehetővé teszik az elemek 
egyenkénti helyreállítását. Az Exchange 5.5-ben ilyen funk- 
ció a Message Journaling, az Exchange 2000-ben pedig az 
adatbázisokra beállítható archiválás. Ezek a technológiák 
minden adatbázist elhagyó vagy oda bekerülő üzenetről ké- 
szítenek egy másolatot, ami az üzenet esetleges törlődése 
után is megmarad és később visszaállítható. 


A téma iránt érdeklődőknek ajánljuk a WSH és a NetAcadé- 
mia Exchange Serverek biztonságáról szóló tanfolyamát. 


Soós Tibor (MCSEx-I, MCT) 


WSH Oktatóközpont 
t.soos owsh.hu 


tech.net 


28 


dpesssssé; 





29 





BUSINESS 


TATE! 


NET. 


Terminal Services Licencing 


Gondoltam valamire: többen is használhatják egy 
időben egymástól független célokra, mi az? A cím- 
ből már sejteni lehet hogy nem egy webkiszolgá- 
lóra - bár akár arra is gondolhattam volna. A 
Terminal Services szolgáltatás lehetővé teszi, 
hogy egy időben a kiszolgáló erőforrásait több 
felhasználó egymástól függetlenül használhas- 
sa. Ma a Terminal Services licencelésével kapcso- 
latos információkat tekintjük át a gyakorlatból 
merített példákon keresztül. Olvashatunk a Terminal 
Services fontos tulajdonságairól, telepítéséről és haszná- 
latáról. Megnézzük közelebbről a Terminal Services licence- 
lésének új eszközét, annak jó és rossz tulajdonságait is. 


A Terminal Services 

A Terminal Services különbözik minden eddig megszokott 
eszköztől, amivel a Windows felett az uralmat átvehettük. 
(Leszámítva Cytrixet, ami a Terminal Services elődje — ezzel e 
cikk keretében nem foglalkozunk). A Terminal Services szol- 
gáltatás segítségével távolról egy teljesen új felhasználói 
felületet (terminált) nyitunk a kiszolgálón, a konzol előtt 
ülő felhasználót nem zavarva. Miért fontos ez? A régebbi 
távfelügyeleti eszközök nagy többsége a számítógép előtt 
ülő felhasználó képernyőjét, egerét és billentyűzetét veszi 
át. A Terminal Services használata esetén a konzolt használó 
felhasználó nem is értesül a többi ügyfél jelenlétéről. A 
Terminal Services egyaránt alkalmazható alacsony költ- 
ségvetésű cégeknél (a régebbi, olcsó kliensgépek kihasz- 
nálásához) és a kiszolgálók távfelügyeletéhez is. 


A Terminal Services szolgáltatáshoz szükséges feltételek 
Terminal Services szolgáltatáshoz rendelkeznünk kell egy 
Windows 2000 vagy Windows NT terminálkiszolgálóval, egy 
hálózati kapcsolattal (ami a TCP/IP mellett gyakorlatilag 
bármi lehet, pl.: VPN; Modem; LAN/WAN; PPTP) egy terminál 
felhasználóval és a szükséges felhasználási engedélyekkel. 
A terminalkiszolgáló a Windows NT 4.0-hoz is elérhető, ami 
a Windows NT 4.0 egy speciális változata: Microsoft Win- 
dows NT 4.0 Teminal Server Edition. Ugyanazokat nyújtja, 
mint a Windows 2000 Terminal Services változata, kivétel 
ez alól a Windows 2000 néhány speciális újdonsága. (Két 
különböző technológiáról van szó egyébként, a közös bennük 
csak a terminálszolgáltatás, mint funkció.) A Windows 2000 
kiszolgálócsalád tartalmazza a Terminal Services és a Termi- 
nal Services Licensing szolgáltatást is. Ezek komponensként 
telepíthetők akár a kiszolgáló telepítésekor és később, a 
már üzembe helyezett kiszolgálóra is (ilyenkor a Control Pa- 
nel Add/Remove Programs moduljában az Add/Remove Win- 
dows Components oldalon kitt-katt) . 


Terminal Services Licensing (TSL) 

A Windows NT 4.0 Terminal Services Edition változatban 
nem volt TSL funkció, annak licencelése teljes mértékben az 
NT licencelésén alapult. Ez néhol jó, néhol kevésbé jó 
megoldásnak bizonyult. 





Windows Components wizard fi; HE 


Windows Components 
You can add or remove components of Windows 2000. 





To add or remove a component, cfick the checkbox. A shaded box means that only 
part of the component wil be installed. To see what: included in a component, cick 
Detads. 
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€. Windows Media Services 


Total disk space reguired: 
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Terminálszolgáltatás és a licencelés telepítése 


A lusta rendszergazdának, akinek a TSL első és második rá- 
nézésre is csak egy újabb felesleges , kütyünek" tűnik, biz- 
tos kellemetlen élményei lesznek. Még az érdeklődő szak- 
emberek körében is akadhat olyan, akinek egy kicsit kelle- 
metlennek tűnhet a TSL használata. Bevallom, én is ezek 
közé sorolom magam - lapzártakor a véleményem egy kicsit 
jó irányba változott. De miért lehet kellemetlen élmé- 
nyünk? Egy gyermekcipőben járó technológiát látunk: ez az 
automatikus licencelés. Az ötlet jó, de még csiszolni kell. 
Remélem, hogy a következő operációs rendszerben a ké- 
nyelmetlen pontok is tökéletesednek. 

Ha röviden szeretném jellemezni, a TSL egy adatbázis, amiből 
az arra jogosult számítógépek licenceket vehetnek ki. Ezeket 
használhatják később a Terminal Services legális eléréséhez. 
Nagy előnye/hátránya (ki-ki döntse el maga :-) a módszernek, 
hogy azok és csak azok férhetnek hozzá a terminálkiszolgáló- 
hoz, akik rendelkeznek a megfelelő licenccel, így ad-hoc , túl- 
hajtásra" nincs lehetőség. A TSL csak a licencek kiosztásával 
foglalkozik, licencek beszerzésére nem használható, és nem 
alkalmas azok visszavonására sem. Sajnos. :-( 


A TSL működése 

A TSL kiszolgáló telepítésére Application Mode-ban telepí- 

tett terminálkiszolgáló esetén van szükség. Hogy a termi- 

nálszolgáltatás módjait megértsük, két fontos fogalmat 
kell megtanulnunk: 

-b Administrative Mode (rendszerfelügyeleti mód): Lehető- 
vé teszi a Windows 2000 operációs rendszer távoli 
felügyeletét, ezzel is csökkentve a rendszer adminisztrá- 
ciós költségeit. Ekkor a Terminal kiszolgálóra csak a 
rendszergazdák jelentkezhetnek be. Egy időben legfel- 
jebb 2 kapcsolat lehetséges, figyelembe véve az aktív és 
inaktív kapcsolatokat egyaránt. Nem igényli a TSL üzem- 
beállítását és TS CAL-t sem kell vásárolnunk. (CAL-Client 

"0 Application Mode (alkalmazásmód): Nem korlátozza az 
egyidejű kapcsolatok számát. A szolgáltatást egyszerű 
felhasználók is igénybe vehetik, programokat futtathat- 
nak a kiszolgálón, mintha az a saját számítógépükön 
futna. Természetesen minden, a kiszolgálón futó alkal- 
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mazás csak a kiszolgáló erőforrásait veszi igénybe. 
Használatához a TSL szolgáltatás telepítésére és akti- 
válására, a felhasználók számára pedig a megfelelő TS 
CAL beszerzésére van szükség. 


Amikor egy alkalmazásmódban működő terminálkiszolgáló- 
hoz csatlakozunk, az egy TSL kiszolgálót keres, majd 
igényli a megfelelő licenceket. 


Microsoft 
Tate Hitelesítő és 
Microsoft Licenckibocsátó 
1 kiszolgáló: Clearing House 
erazszsenzazezszazzaetzaézeémasés KE ALEz EARL EAT RÁSÉS 
j ! 
Ügyfél (mi) Windows 2000 Server 4 


B Terminal Services Licensing 
za —— (licenckiszolgáló) 
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A TSL kiszolgáló működésének elvi rajza 


Az ügyfélgép vagy megkapja a szükséges licencet, vagy a 
kiszolgáló elutasítja az igénylést. Elutasítás abban az eset- 
ben lehetséges ha a TSL kiszolgáló adatbázisában már nem 
található kiosztható licenc. Közvetlenül elutasítást a TSL 
kiszolgálótól nem kapunk - ez alól kivétel az az eset, ha 
nincs kiosztható licenc - ami ha meggondoljuk, nem sze- 
rencsés, hisz így sajnos akár egy kóbor vándor felhasználó 
is ,lenyúlhat" egy licencet, ami ezzel az ő gépére költözik, 
s onnan visszavenni nem lehet. Ez azt jelenti, hogy nem 
tudjuk megmondani a kiszolgálónak, kitől fogadhat el li- 
cenckérelmet és kitől nem. Ezért a terminálkiszolgálóink 
biztonságát a lehető legmagasabb szintre kell emelnünk: 
ha az ügyfelek nem érhetik el a kiszolgálót akkor nem kap- 
hatnak arra a kiszolgálóra érvényes licencet. Miért beszé- 
lünk többes számban a terminálkiszolgálók esetében? Egy 
TSL kiszolgáló több terminálkiszolgálót is elláthat a meg- 
felelő számú ügyfélhozzáférési tanúsítvánnyal (licenc) . Eb- 
ben az esetben -ha egy TSL több terminálkiszolgálóért fe- 
lelős - figyelembe kell venni a felderítési lehetőségeket is. 
A terminálkiszolgáló induláskor keres egy TSL kiszolgálót. 
A tartományban érvényes tartományvezérlők után - ha ez 
szükséges - az Active Directory-ban is keres a TSL kiszol- 
gálók után. Amennyiben ez sem jár sikerrel, broadcast üze- 
netszórással próbálja felderíteni a legközelebbi TSL kiszol- 
gálót. Ezt a terminálkiszolgáló 15 percenként megismétli 
függetlenül attól, hogy talált TSL kiszolgálót, vagy nem, a 
talált TSL kiszolgálókat pedig felveszi a listájába. Ez Mic- 
rosoft Windows NT 4.0-s tartomány esetén egy broadcast 
üzenetet, Active Directory tartomány esetén pedig a DDNS 
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kiszolgáló adatbázisának lekérdezését jelenti. Pontosítsuk 
egy kicsit: Windows 2000-es tartományok esetén a TSL ki- 
szolgálót egy tartományvezérlőre kell telepítenünk. Az al- 
kalmazásmódban telepített terminálkiszolgáló lekérdezi a 
tartomány összes tartományvezérlőjét, majd ezek után 
megállapítja, hogy ezek közül mely kiszolgálók TSL kiszol- 
gálók is egyben. Ezután csatlakozik a hozzá legközelebb 
eső kiszolgálóhoz (a , legközelebbi" kiszolgálót az Active Di- 
rectory telephelyek alapján találja meg). Ez az Enterprise 
Licensing alapja. Windows NT 4.0-s tartományok esetében 
a TSL kiszolgáló felderítése broadcast üzenettel történik. 
A TSL kiszolgáló telepítésével feladatunk még nem ért vé- 
get, hisz most aktiválnunk kell, majd a Client Licence Key 
Pack-et kell telepítenünk. 


TSL kiszolgáló aktiválásának lépései: 
A Terminal Services Licensing kezelőprogram indításakor 
felderíti az elérhető TSL kiszolgálókat. Ha a hálózatunkban 
több TSL kiszolgáló is működik, akkor valószínűleg megta- 
lálja mindent. Ha nem, akkor kezdődhet a hibakeresés, 
aminél figyelembe kell venni a TSL kiszolgálók felderíthe- 
tőségét (DDNS; Broadcast). Az itt példaként használt tar- 
tományban csak egy TSL kiszolgáló van aktiválva tehát a 
képeken csak egy kiszolgáló lesz látható. Az indítás után 
szükség esetén további kiszolgálók is felvehetők, de ehhez 
a megfelelő jogosultsággal is rendelkeznünk kell. Miután 
elindítottuk a TSL kezelőprogramot, láthatjuk a kiszolgá- 
lónkat, melynek bal alsó sarkában egy kis piros jel mutat- 
ja számunkra: a kiszolgálónk nincs aktiválva. Ahhoz, hogy 
a kiszolgálót aktiválhassuk, el kell döntenünk, hogy az ak- 
tiváláshoz szükséges információkhoz milyen úton szeret- 
nénk hozzájutni: 
"8 Internet: Közvetlen, titkosított hálózati kapcsolat 
8 World Wide Web: titkosított kapcsolódás a Microsoft 
Terminal Services webhelyhez 
" Fax 
"8 Telefon 
Az aktiválás varázslót a kiszolgáló nevére jobb gombbal 
kattintva csalhatjuk elő (Activate Server). Itt az első fülön 
lehet a kapcsolat módját kiválasztani. Fax és telefon vá- 
lasztása esetén további információkat is kér a rendszer, 
például az országot ahol vagyunk. Magyarországon nincs 
ilyen ügyfélszolgálat, ezért nemzetközi hívást kell kezde- 
ményeznünk, aminek a minősége sok esetben rossz, sőt 
nagyon rossz. :-( 
A választásunknak megfelelő módon tehát közölnünk kell a 
Microsoft-tal a szükséges adatokat. (A kép csak tájékoztató 
jellegű, egy aktivált kiszolgáló adatlapját ábrázolja) Meg kell 
adnunk a cég adatait, egy kapcsolattartó személy nevét és 
e-mail címét. Ez utóbbi adat nagyon fontos nemcsak ne- 
künk, de úgy tűnik a kibocsátó szervnek is, mert egy felug- 
ró ablakban az e-mail címünket ismét kéri a rendszer. 
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Connection Method ] Licensing Program. Company Information ] Company Adcress ] 


Type your company information below. 

Company MAXTEL Consuling 
Drganizational unit: 

foptional) 

Last neme: [Zoltan 

Fist name: [Harmath 

Phone (optionalk e 3őra0000090 

Ex foptionalk 360a05000050£ 

E-mat Harmath ZotanGmaxelhu 











Terminálkiszolgáló adatlapja 


Az adatlap hiánytalan kitöltése után elkezdődhet a kiszol- 
gáló aktiválásának folyamata, ami nem vesz igénybe sok 
időt és nagy sávszélességet. Akár egy 33.6-s modem sebes- 
sége is megfelel. (Tapasztaltam már olyat, hogy a modem 
nem tudta felvenni a kapcsolatot a Microsoft-tal, de abban 
az esetben a rendelkezésre álló sávszélesség közelített a nul- 
lához). Az aktiválás természetesen más módszerekkel is tör- 
ténhet. A cél a TSL ID megszerzése! Alapvető különbség 
csak a kapcsolat létrehozásában és a használt felületben 
keresendő. Mi történik az aktiválási folyamat során? Na- 
gyon fontos lépés ez a TSL kiszolgálónk életében. Adataink 
a Microsoft Clearing House számítógépéhez kerülnek és ott 
kapunk egy tanúsítványt. Ezzel lesz majd képes a kiszolgá- 
lónk a Microsoft-tal történő titkosított adatforgalom lebo- 
nyolítására. Egy X509-es tanúsítványt (Certificate) kapunk 
vissza, amit a kiszolgálónk eltárol. Önmagában ez még nem 
lenne elég, de az X509-es tanúsítványunk csak a mi gé- 
pünkhöz jó és a telepített Windows 2000 kiszolgálónk soro- 
zatszámával együtt érvényes csak. (Miért jó ez? ld. 2000. 
November: Hálózatunk biztonsága) Kicsit elébe vágtunk a 
dolgoknak. A TSL kiszolgálónak szánt gépünk felveszi a kap- 
csolatot a Microsoft erre hitelesített gépével. Ezek után 3 
lehetőségünk van: 
"0 A megfelelő kód birtokában befejezzük az aktiválási 
folyamatot. 
"0 A megfelelő kódra várva az aktiválási folyamatot később 
fejezzük be. 
"8 Az aktiválási folyamatot visszavonjuk. 
Az első esetet akkor válasszuk, ha a Microsoft-tól a megfe- 
lelő visszajelzést megkaptuk. Esetünkben a visszajelző le- 
vélre várunk. A harmadik lehetőség pedig bármely hiba ese- 
tén megfelelő visszalépést biztosít számunkra. Rövid időn 
belül meg kell kapnunk a visszaigazoló levelet a megadott 
email címre. Az elektronikus levél tartalmaz egy aktiválási 
kódot. Az imént elvégzett módszerrel az aktiválási folyama- 
tot el kell indítanunk, majd ott a második lehetőséget ki- 
választani. Ekkor a 35 karakteres alfanumerikus karakterso- 
rozatot kell begépelnünk (ezt kaptuk meg elektronikus levél 
formában valószínűleg anyanyelvünkön). A rendszer burkol- 
tan figyelmeztet arra, hogy ez a karaktersorozat csak a 
meghatározott sorszámú telepített Windows 2000 kiszolgá- 
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lóval érvényes. Miután ezt begépeltük, a rendszer ismét fel- 
veszi a kapcsolatot a Microsoft erre hitelesített kiszolgálójá- 
val egy titkosított csatornán keresztül. Ezzel számítógépünket 
felkészítettük arra, hogy a Microsoft gépével közös biztonsá- 
gi csatornán kommunikáljon a jövőben. Mit vehettünk észre? 
A csomag (e-mail) ami tartalmazza a megfelelő jelszót, át- 
ment a hálózaton. Van egy közös adat (a kiszolgáló sorozat- 
száma), amelyet a mi gépünk és a Microsoft kiszolgálója is is- 
mer, és amit a megfelelő HASH használatával átalakítva azo- 
nos eredményt kell kapniuk. Klasszikus autentikációról be- 
szélhetünk, ami sokban hasonlít a Windows NT hálózatokban 
már megszokott NTLM és NTLMv2-höz. A különbség csak a ma- 
gasabb titkosítás, mint pl. az NT esetében az NTLMv2 lehet. 
Ennyit a TSL kapcsolatainak biztonságosságáról, most in- 
kább nézzük meg, hogy mi történt akkor, amikor aktiváltuk 
a kiszolgálónkat. Az egyik és legfontosabb, hogy a kiszol- 
gálónk ezentúl bármikor képes felvenni a kapcsolatot a 
Microsoft-tal a megbízotti kapcsolat létrehozásának köszön- 
hetően. A másik nagyon fontos funkció, hogy ezután az al- 
kalmazásmódban telepített kiszolgálónk is működni fog, 
mert létezik a hálózaton egy kiszolgáló aki a tanúsítványok 
kiadását elvégzi. Most a figyelmes olvasó egy kicsit elcso- 
dálkozik: hogy lehetséges ez? Nem is kell CAL? De hisz az 
imént azt mondtam, hogy két dolog szükséges a boldogság- 
hoz: egy aktivált TSL kiszolgáló (megvan) és sok-sok telepí- 
tett CAL (Client Licence Key Pack) - nos ez utóbbit eddig még 
nem telepítettük. Ennek ellenére a TSL kiszolgáló aktiválása 
után minden kérést teljesít - ideiglenes, 90 napos tanúsít- 
ványt oszt ki a kérelmezők részére! A CAL-ok telepítése nél- 
kül az alkalmazásmódban telepített terminálkiszolgálót leg- 
feljebb 90 napon keresztül érhetjük el (bővebben később). 


client Licence Key Pack telepítése: 

A Client Licence Key telepítésével kiszolgálónk alkalmassá 
válik a szükséges és rendelkezésre álló tanúsítványok kiosz- 
tására. A telepítés során szükségünk lesz a CAL ID-re amit 
a CAL beszerzésével azonos időben az eladótól meg kellett 
kapnunk. Ez egy 35 karakteres alfanumerikus kód. A kód 
megadása után a CAL-ok elérhetők, kioszthatók. Amennyi- 
ben ideiglenes CAL-ok is kiosztásra kerültek, azok tulajdo- 
nosai a következő csatlakozáskor a most telepített CAL-ból 
kapnak egyet. MCSP cégek most ne kezdjék el keresni a CAL 
ID-t. Ez egy kicsit komplikáltabb, később szólok erről is. 


CAL-ok telepítése: 

A TS CAL-ok a megszokott csatornákon keresztül szerezhe- 

tők be. A TSL kiszolgáló alapvetően két különböző licence- 

lési formátumot támogat: 

"8 TS CAL: Ezt telepítve meghatározott mennyiségű licenc 
áll rendelkezésünkre. A licencek kiosztásával az új fel- 
használók részére biztosítható licencek száma csökken. 
Gyakorlatilag mindenki választhatja ezt a módszert. 

-8 Terminal Service Internet Connector: lehetővé teszi, 
hogy a terminálkiszolgáló akár 200 egyidejű kapcsola- 
tot is kiszolgáljon anélkül, hogy TS CAL-okat kelljen 
megvásárolni. Ennek használatára csak a Select vásár- 
lók jogosultak. 
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A licencek beszerzése után azokat a Licensing varázsló se- 
gítségével telepíthetjük. Ennek során a már ismertetett 
módok valamelyikéből (telefon; fax; web; Internet) kell vá- 
lasztanunk. Fontos kérdés lehet az, hogy milyen beszerzés- 
ből származik a licenc, amit telepíteni szeretnénk. (Tehát 
tudnunk kell azt, hogy Open Licence, Select, vagy Other ka- 
tegóriába tartozunk.) A választásunknak megfelelően a 
rendszer adatokat kér a szerződéssel kapcsolatosan. A 
szükséges adatok megadása után a telepítés végére érünk, 
ezzel a licencek kioszthatóvá vállnak. 

Solution Providerek esetén ez kicsit nehezebb feladat. A 
szerződés megkötésének pillanatában elérhetővé válik 20 
darab TS CAL, amit fel lehet használni. Ilyenkor a licence- 
lésnél csak és kizárólag a telefonos változatot használhat- 
juk (ez csak a CAL telepítésére vonatkozik), ahol majd a 
megfelelő ID-t megkapva a telepítés befejezhető. Ilyenkor 
szükségünk lesz az MCSP ID-re is. 


CAL-ok élete, azok , védelme": 
Egy újonnan telepített Terminal kiszolgáló (Pear Seat) al- 
kalmazásmódban használva megfelelően működik TSL és 
CAL-ok nélkül is. Ez az átmeneti idő 90 napot jelent. A 90- 
ik napon a Terminal kiszolgáló minden hozzá érkező kérést 
a Server too busy" hibaüzenettel elutasít. A felhasználók 
hozzáférési tanúsítványa nélkül ezután nem működik. Eb- 
ben az esetben csak egy lehetőségünk van (jogi és logikai 
szempontokat vizsgálva): egy TSL kiszolgálót kell üzembe 
helyeznünk, ami CAL-okat fog osztani a felhasználóink szá- 
mára (vásárolt vagy ideiglenes CAL-t). A TSL kiszolgálót a 
fent olvasott módon telepíthetjük és aktiválhatjuk. A ki- 
szolgálónk ettől a lépéstől kezdve képes a Terminál kiszol- 
gáló kérését megfelelően ellátni. Innentől minden kérésre 
ideiglenes, legfeljebb 90 napig érvényes tanúsítványt bo- 
csát ki, ez érvényes a Windows 2000 operációs rendszer- 
családot futtató felhasználói gépekre is. Ismét nyertünk 90 
napot :), de ekkor már égető lehet a probléma, ezért nem 
marad más, mint a TSL CAL-ok beszerzése, azok telepítése 
és megfelelő védelme. A CAL-ok telepítése után a kiszolgá- 
ló minden kérésre egy CAL kiosztásával válaszol, ha annak 
nem látja akadályát. Ha a kérés egy szabályosan telepített 
terminálkiszolgálótól érkezett, azt akkor és csak akkor uta- 
sítja el, ha nincs kiosztható CAL. Ez aggasztó lehet, mert 
fűnek-fának elosztogatja a CAL-okat! Nagyon meg kell 
gondolnunk tetteinket! Mit lehet tenni a CAL-ok fogyása 
ellen? Logikus lenne, ha a TSL kiszolgálónkat kellene véde- 
ni, de nem. A terminálkiszolgálót magát kell védeni, mert 
a TS CAL igénylését indítja el. Ezért a következők valame- 
lyikével védhetjük a CAL-okat: 
"8 A Logon locally (Helyi bejelentkezés) jog erős, nagyon 
erős szabályozása a terminálkiszolgálón. 
"b A terminálelérés korlátozása a terminálkiszolgálón. 
"b IPSec. 

"0 Access this computer from network (Számítógép eléré- 
se hálózaton keresztül) jogosultságok korlátozása. 
Ezek közül valóban fontos és hasznos beállítás a Logon lo- 
cally jogosultsággal rendelkező felhasználók számának 
csökkentése. Mivel a CAL igénylését egy sikeres terminál- 
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bejelentkezés indítja el, ezért ezzel megfelelő módon véd- 
hetjük a kiszolgálónkat (Mi a helyzet a roaming userekkel? 
A szerk.) . További előnye az, hogy nem csökkenti a kiszol- 
gáló funkcionalitását, mint az az IPSec és az Access this 
computer from network jog megvonása esetén tapasztalha- 
tó. A CAL-ok fogyásának ez volt az első példája, de nagyon 
fontos, hogyha egy felhasználói gépet újratelepítünk, az a 
kiosztott CAL-t elveszíti. Mi ennek az oka? A TSL kiszolgá- 
lótól kapott ügyfél-hozzáférési engedélyt az ügyfél számí- 
tógépe a helyi rendszerleíró adatbázisban tárolja. Újratele- 
pítés esetén a rendszerleíró adatbázis bejegyzései eltűn- 
nek, tehát a licenc is! Ekkor fordulhat elő az az eset, hogy 
két azonos nevű számítógép két darab ügyfél-hozzáférési 
tanúsítványt kap. Mit tehetünk ilyenkor? Fel kell vennünk 
a kapcsolatot a Microsoft ügyfélszolgálatával, amihez is- 
mét elő kell keresnünk a CAL ID-t (MCSP cég esetén az 
MCSP ID-t) és persze egy telefont, amiről Írországgal is tu- 
dunk beszélni. (Sajnos hazánkban egyelőre nem vásárolha- 
tó közvetlen írországi forródrót — a szerk.) 


És végül egy hasznos eszköz: 

Windows 2000 Resource Kit-ben található egy eszköz, 
amellyel elemezhetjük a TSL kiszolgálónk adatbázisát. A 
parancssori eszköz neve Lsreport.exe. A program az adat- 
bázisból tabulátor karakterekkel elválasztott szövegfájlba 
írja a kért adatokat. A következő táblázatban az eszköz pa- 
rancssori paraméterei láthatók: 

/F fájlnévA program kimenetét a , fájlnév"-nevű fájlba irá- 
nyítja. (Az alapértelmezett fájlnév az ,,lIsreport.txt") 

/D kezdődátum [végdátum] Csak azokat a licenceket írja 
ki, melyek a kezdődátum és a végdátum között kerültek ki- 
bocsátásra. (A végdátum alapértelmezése az aktuális dátum) 
/T Csak az ideiglenes licenceket listázza. 

Kiszolgálólista Azoknak a kiszolgálóknak a listája, ahonnan 
a program lekérdezi az információt. Ha nem adjuk meg, a 
forrás a tartományvezérlő 

/? A program használatáról ad útmutatót. 


Harmath Zoltán 
MCSE, MCPaI 
Zoleeogeniusgroup.hu 


Zárszó 

Töprengtünk a szerkesztőségben, hogy vajon miért kellett a 
Terminal Services használatát ennyire megnehezítő licence- 
léssel piacra dobni. A magyarázat szerintem abban kere- 
sendő, hogy a TS önmagában olyan , csábos", hogy emiatt 
az egy szolgáltatás miatt esetleg az emberek hajlamosak 
lennének mondjuk Windows 2000 Professionalt VENNI, de 
Advanced Servert HASZNÁLNI. Korábban - valljuk be — ez a 
lehetőség nem volt annyira csábító, mert az NT4 esetén egy 
üres Server nem sok csábos eltérő szolgáltatással rendelek- 
zett egy Workstationhoz képest. 
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A Microsoft Application Center 2000 (továbbiak- 
ban Application Center) a Microsoft .NET kezde- 
ményezés alapját képező Enterprise Server ter- 
mékcsalád része. A termékcsaládot ezen kívül 
többek között a Commerce Server 2000, a 
BizTalk Server 2000 és az SOL Server 2000 ké- 
pezik - további információk a Microsoft .NET 
weboldalán találhatók: 
http: .microsoft.com/net 
Az Application Center célja, hogy megkönnyítse a Win- 
dows 2000- és Internet Information Service 5.0-alapú 
webkiszolgálók telepítését és kezelését. Az Application Center 
segítségével felügyelt webhelyek méretezhetők, robusztusak, 
biztonságosak és könnyen kezelhetők. A webkiszolgálók fürt- 
be rendezésének fő célja az, hogy azok az ügyfél számára to- 
vábbra is csak egy kiszolgálónak látsszanak. A látszat fenntar- 
tásához az kell, hogy a webhely teljes tartalma a fürt minden 
tagkiszolgálóján egyaránt és egyformán jelen legyen; a tarta- 
lom alatt értjük a webhelyet képező statikus információkat, 
fájlokat, regisztrációs adatbázis-kulcsokat, COM-- komponen- 
seket, stb. A fürt ,egészsége", működési paraméterei a telje- 
sítmény-számlálók, felügyeleti eszközök és programozható 
események segítségével könnyen felügyelhető. 


Application Center fürtök 
Az Application Center felhasználásával többrétegű fürtöket 
telepíthetünk, ahol a különböző rétegek különféle terhelés- 
elosztási megoldásokon alapulnak. A terheléselosztásnak kö- 
szönhető az Application Center méretezhetősége és robusz- 
tussága. Kétfajta terheléselosztásról van tehát szó, ezek: 
"0 hálózati terheléselosztás (Network Load 
Balancing, NLB), és 
"8 komponens-terheléselosztás (Component Load 
Balancing, CLB) 
Az Application Center fürt felépítése meghatározza, milyen 
terheléselosztást alkalmazhatunk az adott helyzetben. Álta- 
lában többrétegű (n-tier) környezetben dolgozunk, ahol a 
terheléselosztás a webkiszolgálásánál jelentkezik. Az ilyen- 
kor használt hálózati terheléselosztás (NL8) feladata a 
beérkező IP kérések gyors és folyamatos kiszolgálása. 
A webrétegen működő szoftver (például ASP oldalak) COM-- 
komponenseket használhatnak; a komponensek az adott 
számítógépen, vagy a Distributed COM-nak köszönhetően 
egy távoli gépen futnak. Komponens-terheléselosztás (CLB) 
nélkül ezek a távolból létrehozott objektumok statikusak, 
nem ,foglalkoznak" az azokat futtató gép pillanatnyi terhe- 
lésével. A CLB célja, hogy a hálózati terheléselosztáshoz 
hasonlóan a COM-- objektumok futtatásának terhét is meg- 
ossza a fürtben működő tagkiszolgálók között. (ez a fürt 
nem azonos az NLB fürttel, ld. az ábrát — a szerk.) 
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Tipikus Application Center fürt-felépítés 


Hálózati terheléselosztás 

A hálózati terheléselosztás (NLB) a Windows 2000 
Advanced Server és a Windows 2000 Datacenter Server szol- 
gáltatása. Az NLB a beérkező TCP, UDP és GRE hálózati ter- 
helést elosztja a fürt tagkiszolgálói között. Az elosztás 
alapja egy, a kiszolgálók előzetes terhelési beállításain ala- 
puló, statisztikai algoritmus. Az NLB fürt dinamikusan mé- 
retezhető, automatikusan alkalmazkodik a tagkiszolgálók 
kieséséhez és új tagok munkába állításához (általában anél- 
kül, hogy ebből az ügyfelek bármit is észrevennének) ; a rend- 
szer képes észlelni a tagok működési hibáit, és automatiku- 
san kizárni őket a szolgáltatásból. 

Az Application Center leegyszerűsíti az NLB fürtök kezelé- 
sét. A Cluster Creation Wizard automatikusan elvégzi az NLB 
beállítását, lényegesen egyszerűbben, mintha azt a Win- 
dows 2000-ben nekünk saját kézzel kellene megtennünk. Az 
Application Center segítségével könnyen új tagokat adha- 
tunk a fürthöz, távolíthatunk el onnan, illetve helyezhe- 
tünk üzemen kívül. A hálózati terheléselosztással kapcsola- 
tos további hasznos információk a 
http://www.microsoft.com/windows2000/library/how- 
itworks/cluster/nlb.asp címen találhatók. 


Komponens-terheléselosztás 

A komponens-terheléselosztás (CLB) feladata a COM-- kom- 
ponensek által okozott terhelés elosztása. A COM-- kompo- 
nensek kész szoftverelemek, programozható, különféle 
programozási nyelvekből (például VBScript, ASP, Visual 
Basic, C4--) egyaránt elérhető objektumok. Ezek a kompo- 
nensek képezik a szoftverek újrafelhasználható építőkoc- 
káit. CLB esetén a komponensek egy különálló COM-- kiszol- 
gálófürtön futnak. Ha az alkalmazás egy COM-- objektumot 
szeretne használni, a CLB azt a COM-t- fürt valamelyik tagki- 
szolgálóján hozza létre. Amint az első ábrán látható, az ob- 
jektumot felhasználó üzleti logika a  webrétegen működik, a 
CLB csak a létrehozott COM-4- objektumokat , szórja szét" a 
CLB tagkiszolgálók között. 
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Component Object Model 

A CLB alapja a Component Object Model, más néven COM. 
A COM-kompatíbilis objektumok egy általános felületen ke- 
resztül képesek az általuk megvalósított szolgáltatások 
közzétételére". A megírt COM objektum különböző COM- 
kompatíbilis programozási nyelveken és operációs rendsze- 
rekben módosítás nélkül használható. A rugalmasság kul- 
csa a COM programozói felület (COM interfész). 

A COM komponensek szolgáltatásai az objektum egy vagy 
több interfészén keresztül érhetők el (ezen interfészek egyike 
az, amely a többi interfész lekérdezésére való). A komponens 
használatához olyan programozási nyelvre és környezetre van 
szükség, amely képes kezelni ezeket az interfészeket (például 
az előbb már említett Visual Basic, ASP, VBScript, JavaScript 
vagy éppen a Visual C4--) . Az interfész nem más, mint a támo- 
gatott funkciók (metódusok) kötött formájú táblázata. 





ügyfél 








A COM komponens interfészei 


A COM komponenseket általában .dll-ekben, vagy futtatható 
állományokban (.exe) helyezik el, amely azután szükség ese- 
tén telepíthető a távoli számítógépre is. A távoli objektumok 
elérését a Distributed COM (DCOM) szolgáltatás végzi, távoli 
eljáráshívások (Remote Procedure Calls, RPC) segítségével. 


COM-- Services 

A COM4- Services a Windows 2000 operációs rendszer alap- 
szolgáltatása, ez tartalmazza a COM-alapú szolgáltatásokat 
és a Microsoft Transaction Server-t (MTS). A COM4- Services 
komoly szolgáltatásai közé tartozik a tranzakciókezelés, az 
objektum életpályájának kezelése, a biztonsági szolgálta- 
tások, események és várakozási sort kezelő (vagy azt hasz- 
náló) , úgynevezett gueued komponensek kiszolgálása. 


COM-- komponensek 

A COM4- komponensek olyan COM komponensek, amelyek 
képesek kihasználni a COM- Services szolgáltatásait. A 
COM4- komponensekkel szemben támasztott egyik alapkö- 
vetelmény, hogy információkat hordozzanak önmaguktól. 
A COM architektúra ezekből az alapinformációkból tudja 
megállapítani, hogy az adott komponens milyen COM-- 
szolgáltatást használ vagy támogat (például tranzakcióke- 
zelést, vagy éppen terheléselosztást) . 

A COM4- komponensek alkalmazásokba (Applications) tömörül- 
nek. Ezek az alkalmazások nem azonosak az Application Center 
alkalmazásokkal. A COM5- alkalmazás COM-- objektumok gyűjte- 
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ménye, az Application Center alkalmazás pedig az adott üzleti 
környezetben használt erőforrások (webhelyek, fájlok, COM-4- 
komponensek, regisztrációs adatbázis-kulcsok, stb.) listája. 


A komponens-terheléselosztás működése 

A CLB két fő részből áll: 

-8 A COM4 fürt terheléselosztását felügyelő CLB szoftver 

- A COM-4- fürt (egy Application Center által felügyelt ki 
szolgálófürt, amely COM4- komponensek futtatására való) 


A CLB szoftver 

A CLB szoftver dönti el, hogy egy adott COM-- komponens az 
adott körülmények között melyik tagkiszolgálón jöjjön létre. 
A COM4-. komponenst létrehozó üzleti logika a webrétegen 
működik. Ez a logika általában egy ASP script, amely a 
CreateObject hívást használja a szükséges COM-- komponens 
létrehozásához (ez a kérés mélyebb szinten természetesen 
CoCreatelnstance híváshoz vezet). CLB esetén a komponens 
nem a helyi gépen, hanem a COM fürt (az útválasztási lis- 
ta (routing list) és a válaszidő-táblázat alapján meghatáro- 
zott) tagkiszolgálóján jön létre. A komponens elkészítése 
után a tagkiszolgáló visszaküldi a megfelelő interfészt. A 
CLB az objektum létrehozása után már nem vesz részt a 
rendszer működtetésében (az a DCOM feladata — a szerk.). 


Útválasztási lista (Routing List) 

Az útválasztási lista általában a webrétegen található fürt tag- 
kiszolgálóin található, és a CLB-ben használható COM: fürt tag- 
kiszolgálóinak listáját tartalmazza (ld. az ábrán). Más esetben 
ezt a listát az úgynevezett COM-- útválasztó-fürt is tartalmaz- 
hatja (a COM4- útválasztó-fürt feladata csak az útválasztás, nem 
tartalmaz webréteghez tartozó üzleti logikát) . Cikkünk keretein 
belül csak a webrétegű megoldással foglalkozunk. 
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Table 
A B 18 ms 
C 36 ms 
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A 20 ms 
C 23 ms 
B 58 ms 
D 61 ms 























Útválasztási listák és válaszidő-táblázatok 


Az útválasztási listát a rendszergazda hozza létre a webréte- 
gen működő fürt vezérgépén, ami azután automatikusan eljut 
a fürt többi tagkiszolgálójához. Így a tagkiszolgálók nem tar- 
talmazhatnak különböző COM-- tagkiszolgálókból álló útválasz- 
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tási táblázatokat. Az útválasztási táblázat webrétegen történő 
elhelyezésének előnye, hogy így kiküszöböljük az egypontos hi- 
balehetőséget: ha bármelyik tagkiszolgáló leáll, a többi saját 
táblázatát használva tovább végezheti a munkáját. 


Válaszidő-táblázat (Response Time Table) 
Másodpercenként öt alkalommal (200 ms-onként) a webréteg 
tagkiszolgálóin futó CLB szoftver felveszi a kapcsolatot az út- 
választási listában található COM-- fürt tagkiszolgálóival. A vá- 
laszok megérkezésének pillanatában a CLB szoftver válaszidő- 
táblázatot készít. Minél gyorsabban válaszolt egy COM-t- tagki- 
szolgáló, a táblázatban annál előkelőbb helyen szerepel. A 
webréteg tagkiszolgálója ezután e táblázat alapján dönti el, 
hogy a kért COM-- komponenst melyik COM-t tagkiszolgálón hoz- 
za létre (úgynevezett round-robin módon a kiválasztott ezután a 
táblázat végére kerül, és az eddigi második helyezett lép előre). 
A beérkezett kérés tehát a leggyorsabban válaszoló, legkevés- 
bé terhelt COM-- tagkiszolgálóra kerül, a következő kérések pe- 
dig már máshoz, egészen addig, míg a táblázat ,átfordul". A 
legközelebbi időmérés alkalmával a táblázat frissül, és minden 
elölről kezdődik. Minden CLB szoftvert futtató tagkiszolgáló sa- 
ját válaszidő-táblázatot tart fenn, ez az információ az útválasz- 
tási listával ellentétben nem szinkronizált a tagok között. 


A COM-5- fürt 

A webréteg fürtjéhez hasonlóan a COM-- fürtöt is az Appli- 
cation Center varázslójával hozhatjuk létre. A fürt minden 
tagkiszolgálóján azonos COM-- komponenseknek kell szere- 
pelniük, ezek telepítését külön varázsló könnyíti meg. A 
komponens létrehozása után annak fel kell ismernie, hogy 
egy CLB fürtben működik. 


Fürt-tűrő COM-4. komponensek 

(Cluster Aware COM4- Components) 

A CLB használatához a COM-- komponensnek fel kell tudni is- 
mernie, hogy milyen helyzetben működik. A legfontosabb a 
komponens állapotkezelése. A COM-- komponensek nem tárol- 
hatnak önmagukra vonatkozó állapot-információkat, mert ez 
rossz hatással van a méretezhetőségre és a tranzakció-keze- 
lésre. A méretezhetőséggel azért lehet probléma, mert a 
rosszul megírt objektumokat nem használhatjuk fel újra azok 
újbóli létrehozása vagy inicializálása nélkül. A tranzakcióke- 
zelés bonyolódik, mert a komponensek állapotinformációi 
nem léphetik át a tranzakciók határait. A CLB használatához 
további megkötések szükségesek. A lényeg, hogy a kompo- 
nens nem használhatja ki , helyzeti előnyeit" (bárhol, bárme- 
lyik tagkiszolgálón működnie kell), hiszen a CLB működése 
közben a komponensek bármelyik tagon létrehozhatók. COM-- 
ban például processz-szintű tárhelyet használhatunk ahhoz, 
hogy egy komponens több példánya között megosztott ada- 
tokat tároljunk ott. COM:- fürtben ezzel óvatosan kell bánni, hi- 
szen nincs garancia arra, hogy a komponens példányai ugyana- 
zon a tagkiszolgálón jönnek létre. Ha az újabb példány másik 
tagkiszolgálóra kerül, a processz-szintű információ elveszik. A 
komponensek állapotinformációit közös, állandó, a fürt tagki- 
szolgálói által egyaránt elérhető helyen (pl. DBMS-ben), vagy az 
ügyfél számítógépén (pl. cookie-k segítségével) kell tárolni. 
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A komponens-terheléselosztás telepítése 

A COM: fürt telepítése az alábbi lépésekből áll (a leírás az 

Application Center Beta 2 verzióján alapul): 

1. A fürtök telepítése 
A CLB-hez két fürtre van szükség: az egyik fürt az útvá- 
lasztási listát tartalmazza. Ez a fürt (ahogyan azt az 
előbbiekben is említettük) általában ugyanaz, mint ami 
az ügyfeleket kiszolgálja (webrétegen futó NLB fürt). A 
másik maga a COM-- fürt, ennek telepítéséről az online 
súgóban olvashatunk. 

2. COM4- komponensek telepítése a COM4- fürt 
tagkiszolgálóira 
Az Application Center alkalmazásokat a telepítő varázs- 
ló segítségével más fürtökre is telepíthetjük. Ez főleg 
fejlesztői célra használatos fürtöknél hasznos, amikor a 
folyamatosan változó alkalmazásokat csak időnként 
frissítjük az éles fürtön (ld. ábra). A telepítő varázslót 
a fejlesztői gépen futtatjuk (Stager), ami tartalmazza 
az adott Application Center alkalmazáshoz tartozó 
COM-- komponenseket is. A témáról bővebben a súgó 
,Synchronizing and Deploying Content" fejezete ír. 
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Fejlesztői gép az Application Center-ben 


A telepítő varázsló a COM-- komponenseket alapértelme- 
zésben nem telepíti, mert ahhoz szükség lehet az IIS (és 
esetleg a tagkiszolgáló) újraindítására. A komponensek te- 
lepítése a varázslóban természetesen bekapcsolható. 

Fontos még, hogy a komponensek telepítése során a tel- 
jes fürtöt nem állíthatjuk le. Folyamatos telepítésre van 
szükség, a tagkiszolgálók átmeneti leállítására, majd új- 
raindítására. A Microsoft Application Center 2000 Reso- 
urce Kit további információkat tartalmaz a témáról. 

3. A COM4 komponensek telepítése a webréteg fürtjére 
A CLB használatához természetesen a COM-- komponen- 
seket a webréteg fürtjének tagkiszolgálóira is telepíte- 
ni kell. A telepítő varázsló ebben is segít, de ne felejt- 
sük el, hogy a COM-- komponensek telepítése az IIS, 
esetleg a számítógép újraindításával járhat. Itt is fon- 
tos a folyamatos rendszerfrissítés. Másik fontos ténye- 
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ző, hogy a webréteg tagkiszolgálóin található COM-r 
komponenseknek szinkronban kell lenniük a COM-- fürt 
tagkiszolgálóira telepített példányokkal (ld. még: Mic- 
rosoft Application Center 2000 Resource Kit) 

4. CLB-támogatás beállítása a webrétegre telepített 
COM-- komponensekben 
A webréteg tagkiszolgálóira telepített komponenseket 
be kell állítani a CLB támogatásához. Ehhez a Compo- 
nent Services Explorer-t használhatjuk, ami az Applica- 
tion Center MMC modulján keresztül érhető el. Az adott 
komponens kiválasztása után a tulajdonságlap Activa- 
tion oldalán jelöljük be a Component supports dynamic 
load balancing jelölőnégyzetet. 

5. Az útválasztási lista felépítése 
Az útválasztási listát a webréteg fürtjének vezérkiszol- 
gálóján hozzuk létre, majd az automatikusan eljut a 
többi tagkiszolgálóra. A COM-- fürt tagkiszolgálóinak 
listája az Application Center felügyeleti moduljában, a 
webréteg fürtjének tulajdonságlapján, a Services olda- 
lon állítható be. 

Ennyi. Miután mindent telepítettünk, a webrétegen futó 

alkalmazás a COM-- fürt tagkiszolgálóin futó komponense- 

ket használja majd. 





A Component Load Balancing működés közben 

Lássuk, hogyan bizonyosodhatunk meg gyorsan a CLB mű- 

ködéséről. Feltesszük, hogy egy fejlesztői gép segítségével 

telepítjük majd a szükséges elemeket a webréteg és a 

COM-- fürt tagkiszolgálóira. 

1. A fejlesztői gépen Visual Basic segítségével hozzunk 
létre egy COM-- komponenst, ami a következő metódust 
tartalmazza: 

Public Function GetName() As String 
Set WS - CreateObject 
("wscript.network") 
GetName -— WS.Computername 
Set WS-nothing 
End Function 
2. A COM4- Services Explorer segítségével a komponenst 
rendeljük hozzá egy COM4- alkalmazáshoz. 
3. A fejlesztői gépen hozzunk létre egy Application Center 
alkalmazást, ami tartalmazza a COM-- komponenst. 
4. Telepítsük a komponenst a COM-- fürtre. Ne felejtsük el 
a Deploy COM-- applications opciót kiválasztani, külön- 
ben a komponens nem települ fel. 
5. Készítsük el a default.asp-t az alábbi tartalommal 
(természetesen a YourComponent. YourcClass helyére az álta- 
lunk létrehozott új komponens ProgID-ját írjuk — a szerk. ): 
Zscript language-vbscript 
runat-—"server"5 
for n-1 to 50 
set xscreateobject 

( "YourComponent . YourClass") 
Response.Write "Component created on: 
Response.Write x.GetName 
Response.write "cbr2" 
set x-nothing 
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next 
£/script2 

6. A fejlesztői gépen hozzunk létre egy újabb Application 
Center alkalmazást, ami a default.asp-t és a COM- 
komponensünket tartalmazza. 

7. Telepítsük az alkalmazás a webrétegre. 

8. Ellenőrizzük (készítsük el) a webréteg útválasztási lis- 
táit és állítsuk be a COM4- komponensek CLB-támogatását. 

9. Egy ügyfélgépen nyissuk meg a default.asp oldalt. Ha 
elsőre nem működik, előfordulhat, hogy az IIS éppen 
újraindul (a komponens-telepítés miatt). 

Ha minden jól ment, a képernyőn megjelenik a komponens 

példányait futtató COM-- fürt tagkiszolgálóinak neve. 


Mikor használjuk a CLB-t? 

A CLB nagyszerű megoldás elosztott környezetek építésé- 
re. Néha azonban a CLB használata nem ajánlott, például, 
ha a teljesítmény, a méretezhetőség és a biztonság fontos 
szempont. Lássuk, mi indokolja a fenti állítást: 
Teljesítmény 

Bármilyen jó is egy webhely, nem lesz sikeres, amíg nem 
produkál megfelelő teljesítményt. Két fontos szempont az 
adatátvitel és a válaszidő, a CLB használata mindkét té- 
nyezőre hatással van. 

Átvitt adatmennyiség 

Az átviteli teljesítmény meghatározza, hogy mikor használ- 
hatunk hálózaton keresztüli eljáráshívást. A CLB természe- 
tesen rontja ezt a teljesítményt, ezért a fürtök tervezésénél 
ezt figyelembe kell venni. A táblázatban látható, milyen 
teljesítménnyel működik egy egyszerű , Hello, world" szöve- 
get visszaadó COM-- komponens különféle környezetben: 





Környezet Hívás / mp. Relatív sebessé: 
COM-- kiszolgálóalkalmazás 625 1.0x 

COM-- kiszolgálóalkalmazás 1923 3.08x 
(.exe), helyi gép, out-of- 

BTOSÉ SS snzsésénéeeetensááésíszáttszezseee SEN 
COM4- library alkalmazás 3333 5.33x 


Világos, hogy a hálózaton keresztüli eljáráshívás jóval las- 
sabb, mint a helyi gépen futó objektumok használata. Ez 
minden szoftverre igaz, legyen az Microsoft, vagy más. 
Ezért, ha az átviteli teljesítmény nagyon fontos, a CLB nem 
biztos, hogy jó választás. Ilyenkor a komponenseket érde- 
mes a webréteg tagkiszolgálóira telepíteni. A CLB támoga- 
tás elveszik, de a terheléselosztás az NLB-nek köszönhe- 
tően továbbra is elérhető. 
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COM34. komponensek a webréteg fürtjében 


Válaszidő 

A webhelyek válaszideje nagyon fontos, és a webhely felépí- 
tése a válaszidőt nagyban befolyásolja. A webrétegen futó 
COM-- komponensek ronthatják a webkiszolgáló teljesítmé- 
nyét. Ha a nem COM--alapú működés válaszideje fontos, a 
komponenseket érdemes külön COM-- kiszolgálófürtre telepí- 
teni. Ez csökkenti a webkiszolgálók terhelését, és csökkenti 
a válaszidőt azon ügyfelek felé, akik nem használnak COM-- 
alapú szolgáltatást (például statikus weblapokat töltenek le). 
Mások számára a hálózati működés miatt a teljesítmény va- 
lószínűleg csökkenni fog. Másik lehetőség, hogy az útválasz- 
tási listákat is külön fürtre telepítjük, így még több teljesít- 
ményt szabadítunk fel a webkiszolgálókon. 

Világos, hogy a nagy teljesítmény és a CLB nem minden esetben 
fér össze, ezt a rendszer tervezésekor figyelembe kell venni. 


Kezelhetőség 

Külön COM-- fürtök használata megkönnyíti a rendszer keze- 
lését. Segítségével elkülöníthető a COM-- komponensek és a 
hálózati kérések kiszolgálása és kezelése. Lehetőség van ar- 
ra is, hogy egy COM-- fürt több webrétegen futó, független 
fürtöt szolgáljon ki, és viszont. 

Biztonság 

A CLB-t sokszor a webkiszolgáló biztonságának növelésére 
használjuk. Ha a COM4- komponensek feladata az adatok ke- 
zelése, azok biztonságosan érik ez azokat. Ha a komponens 
a webkiszolgálón fut, könnyebben elérhető (és támadható), 
mintha az külön tagkiszolgálón működik. A COM-- fürtöt ál- 
talában tűzfal védi (az ábrán ez a Firewall B), ami megaka- 
dályozhatja például azt, hogy egy komponenst az ügyfél 
önmaga hozzon létre, és azzal visszaéljen (pl. COM-- kérése- 
ket csak a webréteg fürtjétől fogadunk el). Az ábrán látható 
demilitarizált zóna (DMZ) a webréteg fürtjét védi két oldal- 
ról, két tűzfal segítségével. 
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COM4- fürt tűzfalak mögött 


Összefoglalás 

A CLB nagyszerű megoldás elosztott alkalmazások fejleszté- 
séhez, de óvatosan kell használni. A CLB használata ront- 
hatja a teljesítményt, de ezt ellensúlyozzák előnyei: a mé- 
retezhetőség, biztonság, a könnyű telepítés és a terhelés- 
elosztás. Széleskörű használata megkönnyíti majd a .net-a- 
lapú megoldások fejlesztését. 


További információk 
http://www.Microsoft.com/ApplicationCenter - Legfris- 
sebb információk a Microsoft Application Center 2000-ről 
Microsoft Application Center 2000 Resource Kit - Az 
Application Center-rel kapcsolatos mélyebb ismeretek tár- 
háza. Nemsokára megjelenik. 
http://www.microsoft.com/com - COM és COM-- információk. 


http://www.microsoft.com/net - További információk 
a .NET-ről. 


http://www.microsoft.com/windows2000 


/library/howitworks/cluster/nlb.asp - 


Hálózati terheléselosztás 
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Március elseje óta az ISZT (Internet Szolgáltatók tanácsa) li- 
beralizálta a domainnév regisztrációt. Sokan azonban fél- 
reértik a szabadságot, és úgy vélik, hogy eljőve az ő idejük, 
hatalmas anyagi előnyre tehetnek szert. A következőkben 
azt szeretném körüljárni, hogy hol van a határa a szabad- 
ságnak, mi jelent korlátot és miért. 
A március elsejei változás, a liberalizálás azt jelenti, hogy 
amíg korábban csak a cégjegyzékbe bejegyzett cég a cégne- 
vével azonos, vagy lapengedély alapján a lap címével azo- 
határnaptól kezdve bárki, tehát magánszemély is jogosult 
arra, hogy akár fantázianéven is domaint igényeljen. 
A szabadság azonban csak addig terjedhet, amíg az más 
jogát, jogos érdekét nem sérti. A domainnév igénylésekor 
az igénylőlapon az aláíró külön nyilatkozik arról is, hogy a 
domain kiválasztásában a megfelelő gondosságot tanúsí- 
totta, és meggyőződött arról a cégjegyzék, illetve a Magyar 
Szabadalmi Hivatal által a web-en közzétett védjegy lista 
tanulmányozását követően, hogy a választott domain nem 
jogsértő. Természetesen a gyakorlatban az igénylők egy ré- 
sze úgy írja alá az igénylőlapot, hogy e gondossági köve- 
telménynek nem tesz eleget, illetve a domainbrókerségre 
törekvők éppen annak tudatában csapnának le az adott jól 
csengő kereskedelmi névre, hogy azt majd jó pénzért ad- 
ják át az arra jogosultnak. 
Domain igénylése esetén prioritással rendelkeznek azok, 
akiknek a (rövidített) cégneve vagy bejegyzett védjegye 
azonos a domainként igényelt karakterekkel. A prioritással 
nem rendelkezők igényét két hétre , várólistára" helyezik, és 
ez alatt a két hét alatt bárki (tehát nem csak a jogosult!) ki- 
fogást terjeszthet elő az igényléssel szemben. Ez esetben az 
igénylésről és a kifogásról egy tanácsadó testület állásfog- 
lalásának kikérése után határoz a regisztrátor. Abban az 
esetben, ha kifogás nem érkezik be, a domain automatiku- 
san regisztrálásra kerül. A regisztrációt követően ébredő 
védjegy-jogosult, vagy akinek cégneve, illetve kereskedelmi 
neve az adott domain, a bíróságnál keresheti igazát. Bírói 
fórumok között azonban lehet választani, és a hagyomá- 
nyos, köztudottan a nagy ügyhátralék miatt lassú rendes bí- 
róság helyett a kérdésben járatosabb, tapasztalatokkal is 
rendelkező jogászokból és informatikai szakemberekből 
összeállított, gyorsan (három hónapon belül) döntő válasz- 
tott bíróságot is igénybe lehet venni. 
Mivel magam is jártam már el választott bíróként domaini- 
gényléssel kapcsolatos ügyekben, így tapasztalatból állítom, 
hogy a három tagú bírói testület bizony nincs könnyű hely- 
zetben. Milyen döntést hozzon a bíróság például abban az 
esetben, ha a madonna.com domainnevet egy magánsze- 
mély nyilvánvalóan eladási céllal igényelte? Ha érdekli, mi 
történik az informatika és a jog határvidékén (BSA, digitális 
aláírás, szerzői jog, tartalomfelelősség) iratkozzon fel a 
Páneurópa Jogász Unió levelezési listájára! Csatlakozás: 
net-join Olyrs.pju.hu (üres levéllel). Levelezés: legal- 
netolyrs.pju.hu A madonna szó igen elterjedt szerte a vi- 
lágban, és az énekesnő mellett számos egyház, alapítvány, 
stb. nevében is szerepel. Számít-e ilyen esetben, hogy 
ugyanez a szó védjegyoltalom alatt áll az ismert énekesnő 
javára? Az ügyet eldöntő választott bíróság végül az énekes- 
nőnek adott igazat, annak ellenére, hogy az igénylő ingye- 
nesen tovább akarta ajándékozni a domaint a Madonna ne- 
vet viselő karitatív alapítványnak. Hasonló eset történt is- 
mert likőrgyárosunk nevével megegyező domain esetében, 
és a közkedvelt italt, valamint a tulajdonos nevét is jelentő 





— — JOGI  ESETEK 
Domainregisztráció 


domain átadására kötelezték az igénylőt. Kicsit ne- 
hezebb a helyzet akkor, ha a piacon csak egy 
meghatározott réteg által ismert és kedvelt ter- 
mék márkaneve, amely egyben védjegyoltalom 
alatt is áll kerül domainként regisztrálásra. 
Történetesen e márkanévnek egyidejűleg más 
jelentése is ismert. Vajon ez esetben is megil- 
leti-e a védelem a védjegy jogosultját a piac 
más területén tevékenykedő igénylővel szem- 
ben? Automatikusan, csak a védjegyoltalomból kö- 
vetkeztetve, ilyen védelemre nem tarthat igényt. A 
védjegy ugyanis nem általános védelmet jelent, hanem 
meghatározott árucsoport, áruosztály védjegye. Más terüle- 
ten ugyanakkor ugyanazon szóösszetétel használata a piac 
más áruira nézve nem tilos. Gondoljunk például a sport cso- 
koládéra. Ilyen néven nyilván nem lehet más édességet for- 
galomba hozni, és ha a domain igénylője a sport.hu-t más 
édesség eladásra kívánja használni, úgy nyilván sérti a sport 
csokoládé gyártójának jogait. De ha ugyanilyen domain 
alatt sporthíreket tesz közzé, akkor a csokoládé gyártója 
alaptalanul próbálna fellépni. Ez utóbbi esetben azonban 
már a tartalom is döntő lehet a vita megítélésében. A tarta- 
lomról, annak jogsértő jellegéről azonban majd egy követ- 
kező cikkben írok részletesebben. 

E néhány gondolattal arra kívántam rámutatni, hogy a do- 
mainnevekkel kapcsolatos problémák koránt sem egyértel- 
műek, és megítélésük, biztos álláspontból való eldöntésük 
bizony még a bíró gyakorlat további fejlődését feltételezik. 
A jog azonban konzervatív és természeténél fogva lassan 
reagál a világ új és új kihívásaira, így sem a jogalkotók, sem 
a jogalkalmazók szemére nem vethető, hogy az Internet 
robbanásszerű terjedésével újonnan felvetődő kérdésekre 
még csak nehezen találnak választ. 





Dr. Mayer Erika 


Ügyvéd 
a Páneurópa Jogász Unió elnöke 
mayer(onadas-mayer.hu 


A domainregisztrációval kapcsolatos tudnivalók, az általá- 
nos szabályozás, a regisztrációt végző szervezetek (regiszt- 
rátorok) és a cikkben is említett kéthetes várólista a 
http://www.nic.hu címen érhető el. Ezen a címen el- 
lenőrizhetjük azt is, hogy az általunk igényelni tervezett 
domainnév szabad-e még, vagy az már valakinek a tulaj- 


donába került. (http://www.nic.hu/domainsearch/) 
[mICK] 
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. Osszetett lekérdezések 


Az előző cikkünkben belemélyedtünk az illesztések 

lelkivilágába. Megnéztük, hogy egymásba ágya- 

zott lekérdezésekkel milyen egyszerűen meg le- 

het oldani bonyolult problémákat is. Most to- 

vábbi igen hasznos nyelvi elemekkel ismerke- 

dünk meg, amelyek segítségével csoportosít- 

hatjuk adatainkat, műveleteket végezhetünk a 

csoportokkal, és nagyon látványos riportokat tu- 

dunk készíteni. Ehhez kapcsolódóan megnézzük, 

hogy a szerverbe beépített függvények segítségével 
mennyire át lehet alakítani az adatok jelentését. 


Csoportosítsunk! 
Bemelegítésül nézzük meg az alábbi lekérdezést: 


SELECT 
od.OrderID, p.ProductName, 
od.UnitPrice r od.Ouantity AS Amount 
FROM 
[Order Details] od 


INNER JOIN 

Products p 
ON 

od.ProductID - p.ProductID 
ORDER BY 

OrderID 
OrderID ProductName Amount 
10248 Oueso Cabrales 168.00 
10248 Singaporean 98.00 
10248 Mozzarella 174.00 
10249 Tofu 167.40 


Egyszerűen kilistáztuk a megrendeléseket, kiszámolva az adott 
tétel értékét (od.UnitPrice " od.Ouantity). Szép ez a lista, csak 
túl részletes. Például a 10248-as megrendeléshez három sort lis- 
tázott ki, mert a megrendelés három altételből állt. Egy riport- 
ban nem érdekesek az ilyen részletek, általában csak arra van 
szükség, hogy egy megrendelés összesen mekkora értékű volt. 
Első felindulásunkban a már ismertetett SUM függvényt hasz- 
nálnánk, ami képes arra, hogy összegezze a tételeinket: 


SUM(od.UnitPrice t od.Ouantity) AS Amount 


Persze ez nem azt tenné, amit várnánk tőle, hanem az összes 
megrendelés értékét összeadná, és eredményül egy számot 
kapnánk, amelyben minden megrendelés együttes értéke len- 
ne. Mi lenne, ha lenne olyan utasításunk, amivel megmond- 
hatnánk, hogy csoportosítsa a sorokat az OrderID mező alap- 
ján, és a csoportokra végezze el az összegzést? Természetesen 
van ilyenünk, a GROUP BY az. Segítségével a GROUP BY mögé 
írt oszlopok szerint történik az eredményhalmaz csoportosítá- 
sa, azaz az azonos OrderID-jú sorokból egyet készít, és a cso- 
portokra kiszámítja az aggregált eredményeket. 

Alakítsuk át a példánkat úgy, hogy megrendelésenként összeg- 
zett listát készítsen a GROUP BY és a SUM segítségével: 


SELECT 
od.OrderID, 
SUM(od.UnitPrice tr od.Ouantity) 
AS Amount 
FROM 
(Order Details] od 
INNER JOIN" 
Products p 


ON 
od.ProductID - p.ProductID 
GROUP BY 
od.OrderID 
ORDER BY 
OrderID 
OrderID Amount 
10248 440.00 
10249 1863.40 
10250 1813.00 


Nagyszerűen működik! Miért vettem ki a p.ProductName oszlopot? 
Azért, mert semmi értelme, hisz pont az volt a célunk, hogy termé- 
kektől és megrendelés tételektől független listát kapjunk. Ha ezt el- 
felejtenénk, figyelmeztetni fog a szerver: 


Column "p.ProductName" is invalid in the se- 
lect list because it is not contained in ei- 
ther an aggregate function or the GROUP BY 
clause. 


Azaz a fordító a p.ProductName-et csak akkor fogadja el SELECT 
mögött, ha azt vagy felsoroljuk a GROUP BY-ban, vagy egy agg- 
regáló függvénybe foglaljuk bele. Az előbbinek az lenne a kö- 
vetkezménye, hogy a megrendelés tételeken belül terméken- 
ként tovább lenne bontva a részösszeg. Sokszor ez is cél lehet. 
A második javaslattal kapcsolatban: nehéz lenne olyan beépí- 
tett aggregáló függvényt keresni, ami a terméknéven valami 
hasznosat tudna végezni. Úgyhogy ezt felejtsük el. 

Mi van, ha csak azokat a megrendeléseket akarjuk kilistázni, 
amelyek összmegrendelés értéke nagyobb, mint 1000$? A 
WHERE használata sajnos nem vezet eredményre, mert az csak 
az egyes Order Details sorokban található értékekre tud szűr- 
ni, és nem pedig azok összegére. Másképpen fogalmazva vala- 
mi ilyesmit szeretnénk látni a WHERE-ben: 


WHERE 
SUM(od.UnitPrice tr od.Ouantity) 53 1000 


vagy 
WHERE Amount 5 1000 


Csakhogy a WHERE-ben nem lehet használni aggregáló függ- 
vényeket, így a SUM-ot sem. Hogyan juthatunk túl ezen a di- 
lemmán? Úgy, hogy van egy olyan speciális záradék (clause), 
amelyet arra találtak ki, hogy a GROUP BY által definiált cso- 
porton lehessen vele feltételeket érvényesíteni. Ez a záradék a 
HAVING. A HAVING nagyon hasonló a WHERE-hez, a különbség 
abban rejlik, hogy a záradékok után álló kifejezés mikor kerül 
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kiértékelésre. A WHERE után álló kifejezést a csoportosítás 
előtt értékeli ki a végrehajtó egység, azaz a WHERE segítségé- 
vel előre kiválogatjuk azokat a sorokat, amelyeket csoportosí- 
tani szeretnénk. Ezután jön maga a GROUP BY-ban előírt cso- 
portosító művelet. Létrejönnek a csoportok, valamint kiszámí- 
tódnak a csoportokra kijelölt aggregáló kifejezések. Ekkor jön 
a képbe a HAVING. A parancsvégrehajtó kidobálja azokat a 
csoportokat, amelyekre nem teljesül a HAVING után álló felté- 
tel. A szenzációs az a dologban, hogy a HAVING után használ- 
hatunk aggregáló függvényeket, ellentétben a WHERE-el! 
Mivel a WHERE segítségével drasztikusan le lehet csökkente- 
ni a csoportosítandó sorok számát, ezért érdemes minden 
olyan feltételt, ami nem a csoportokra vonatkozik a WHERE- 
be rakni a HAVING helyett. Ha ellenkezően cselekszünk, a for- 
dító nem fog figyelmeztetni minket. ő szolgai módon végre- 
hajtja a lekérdezést az általunk előírt módon. A felhasználók 
viszont szólnak majd az alkalmazásunk lassúsága miatt... 
Szerencsére azonban a Ouery Optimizer ennél okosabb. Álta- 
lában, hangsúlyozom, általában észreveszi, hogy nem opti- 
málisan írtuk meg a lekérdezést, és a nem megfelelő helyre írt 
kifejezéseket a végrehajtás idejére átrakja a megfelelő helyre. 
Még sokszor tapasztaluk majd, ahogy az SOL Server fejlesztők 
intelligenciája igyekszik pótolni a buta alkalmazásfejlesztőét. 
Hogy érthetőbb legyen a HAVING és a WHERE közötti különb- 
ség, egy táblázatban összefoglaltam, hogy milyen helyzetben 
melyik záradékot használhatjuk. 


WHERE 
A csoportosítás 
előtt 


HAVING 
A csoportosítás 
után 


Mikor szűr? 





Tartalmazhat-e 
aggregáló 
függvényeket? 





Nézzünk egy példát, amelynek segítségével közelebb kerülhetünk 
a GROUP BY és a HAVING szelleméhez. Lássunk egy elég bonyo- 
lult lekérdezést, amiben minden benne van, amit eddig tanultunk: 


SELECT 
P.ProductID, p.ProductName, 


"Amount" - SUM(od.UnitPrice § 
od.Ouantity) 
FROM 
(Order Details] od 
INNER JOIN 
Orders o 
ON 
0.OrderID - od.OrderID 
INNER JOIN 
Products p 
ON 
P.ProductID - od.ProductID 
WHERE 
0.OrderDate 57 "1998.05.05" AND 
o0.OrderDate c- "1998.05.07" 


GROUP BY 
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P.-ProductID, ProductName 
HAVING 

SUM(od.UnitPrice tr od.Ouantity) 2 800 
ORDER BY 


Amount DESC 


Az SOL kód magyarra fordítása: készítsünk egy olyan listát, 
amely az 1998. május ötödike és hetedike közötti megrende- 
lések összértékét listázza ki, termékenkénti bontásban. Csak 
azokra a termékekre vagyunk kíváncsiak, amelyek megrende- 
léseinek összege nagyobb, mint 800 dollár. A lista legyen ren- 
dezve az eladási érték alapján, csökkenő sorrendben. Huh, 
magyarul nehezebb megfogalmazni, mint SOL-ül! Nézzük meg 
a kimenetét: 


ProductID ProductName Amount 

64 Wimmers gute 4389 
2 Chang 1178 

16 Pavlova 802 


Néhány szó a szintaktikával kapcsolatban. Az 


"Amount" z- SUM(od.UnitPrice § 
od.Ouantity) 
kifejezés a 


SUM(od.UnitPrice § 
od.Ouantity) AS Amount 


kifejezéssel egyenértékű. Lehet így is írni, meg úgy is írni. 
Használjuk az, amelyik olvashatóbb számunkra. A leglustáb- 
bak a második formát használják, úgy, hogy még az AS-t is el- 
hagyják (én is ilyen vagyok). 

Az ORDER BY-ban az Amount álnevet használhattuk a bonyo- 
lult SUM(od.UnitPrice " od.Ouantity) helyett. Ezt a szintakti- 
kai könnyítést sajnos csak az ORDER BY-ban használhatjuk ki, 
a HAVING-ben már nem. Kár. 

Az 


"1998.05.05" 
"1998.05.07" 


0.OrderDate 5- AND 


o0.OrderDate cs 


szűrőfeltételt elegánsabban is megfogalmazhatjuk a BETWEEN 
operátor segítségével: 


OrderDate BETWEEN 
"1998.05.05" AND "1998.05.07" 

A két kifejezés logikai értéke azonos. 

Gyakori kérés a marketing vagy a pénzügy részéről, hogy 
olyan összesített statisztikát kérnek, amelyben az eladási 
adatok napi bontásban láthatók. Mivel a generálódó listát 
emberek fogják kiértékelni, ezért őket elsősorban az irányvo- 
nalak érdeklik, nem pedig az összes részeredmény az utolsó 
bitig. Így például feltételként szabják, hogy a napi listában 
csak azok a termékek szerepeljenek, amelyekből több mint 
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egyet rendeltek meg egy adott napon (a nap slágere): 


SELECT 
Orderpate, 
P.-ProductName, 
"Amount" -— 
SUM(od.UnitPrice t od.Ouantity), 
COUNT(tr) AS OrderedProducts 
FROM 
. --ugyanaz, mint az előző lekérdezésben 
WHERE 
OrderDate BETWEEN 
"1998.05.01" AND "1998.05.07" 
GROUP BY 
OrderDate, p.ProductID, ProductName 
HAVING 
COUNT(") 51 
ORDER BY 
OrderDate, Amount DESC 


OrderDate ProductName Amount OProd 
1998-05-0O5 Chang 532 2 
1998-05-06 Chang 646 2 
1998-05-06 Grandma "s 525 2 
1998-05-06 Tofu 488 2 


Ebből olyan okosságokra lehet következtetni, hogy a Chang 
nagyon finom lehet, mert ötödikén és hatodikán is megren- 
deltek belőle kettőt is! Ennél tovább azonban nem megyünk, 
ez nem a mi szakmánk. 

Szakmai szempontból az utolsó oszlop érdekes a számunkra: 
COUNT(r) AS OrderedProducts. A COUNT(r) a többi 
aggregáló függvényhez hasonlóan másként viselkedik, ha 
GROUP BY van a közelben: nem az egyedi sorokat számolja 
meg, hanem a csoportokon belüli sorok számát. Másképpen: 
nem a teljes eredményhalmazra ad egy eredményt, hanem 
minden egyes csoportra külön-külön. Pont ez az, ami nekünk 
kellett, és a HAVING volt olyan szíves aggregáló függvényt 
beengedni a feltételek közé. Hurrá! 


Beépített skaláris függvények 

Mi is az a skaláris függvény? A függvény állatfaj azon alfaja, 
amely egy értékből egy értékre képez le. Azaz nem olyan, mint 
a SUM volt, ami sok sor tartalmát összegezve adott vissza egyet- 
len számot, mert ő az aggregáló típusú függvények képviselője, 
azaz, amelyek több értékből állítanak elő egyet. Inkább gondol- 
junk az abszolút értéket képző ABS függvényre (a blokkolásgát- 
ló függvény :). ABS(-4) -— 4. Azaz a mínusz négyet leképezte 
plusz négyre. Nagy csodák vannak ebben a Serverben! 

Az SOL Server nagyon sok beépített, skaláris függvénnyel ren- 
delkezik. Vannak matematikai célúak: abszolút érték (ABS), 
trigonometrikus függvények (SIN, COS, TAN, COT, valamint 
ezek arcus megfelelői), logaritmus függvények (LOG, L0G10), 
exponenciális függvény (EXP), kerekítések (ROUND, FLOOR, 
CEILING) , véletlen szám generáló függvény (RAND) stb. Majd- 
nem olyan gazdag a kínálat, mint más , polgári" nyelvekben, 
mint pl. a Visual Basic-ben. 

Van nagyon sok szövegkezelő függvény: különböző darabolá- 
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sok (LEFT, RIGHT, SUBSTRING), szövegdarabok keresése (PA- 
TINDEX, CHARINDEX), kis-nagybetű konvertálók (UPPER, LO- 
WER), számformátumról szövegre átalakító (STR), kezdő és 
záró szóközt levágó (LTRIM, RTRIM). Vannak egzotikusabbak 
is: REVERSE, ami megfordít egy szöveget: , cirmos" $ ,som- 
ric". Van olyan, ami nagyon hasznos lenne, ha magyarul is 
működne, csak hát a magyar nyelv elég ellenálló a formalizá- 
lással szemben: a DIFFERENCE és a SOUNDEX. A DIFFERENCE 
egy 0-4-es skálán képes megmondani két szövegről, hogy ki- 
mondva, hangzásban (!) mennyire hasonlítanak. Nem a ka- 
rakterláncok írt, hanem kimondott formája. Ez a szolgáltatás 
nagyon jól jönne például egy telefonkönyv alkalmazásnál, 
ahol nem lehet tudni, hogy pontosan hogyan írtak egy nevet, 
de például valahogy úgy hangzott, hogy ,socó". A , Smith" és 
a ,Smythef-re a például DIFFERENCE azt mondja, hogy a tá- 
volságuk 4, azaz nagyon hasonlítanak. Az , other" és a ,bro- 
ther" szavak 2 távolságra vannak egymásra, azaz még hason- 
lítanak, de azért nem annyira. Nagyon jó lenne ez magyarul 
is! Így talán a Gizike és a gőzeke is kaphatna egy 1-est. 
Tovább a függvények útján. Nagyon hasznosak, bár ritkábban 
használatosak az úgynevezett metaadat-függvények. Ezek a 
rendszertáblákból kérdeznek le adatokat (manuálisan tilos, 
mert bármelyik szervizcsomag megváltoztathatja) , melynek se- 
gítségével belső információkat lehet megtudni az adatbázi- 
sunk tulajdonságairól. Ha például az alkalmazásunk kíváncsi, 
hogy a Employee nevű tábla FirstName nevű oszlopa hány 
byte-ot foglalhat el az adatbázisban: 


COL LENGTH ("Employee", "FirstName") 


Ez egy nvarchar(50)-es oszlopra 100-at adna eredményül (az 
nvarchar Unicode formátumú, azaz minden karakter 2 bájtot 
foglal el). 

További függvénykategóriákat is találunk még a Serverben, de 
ezeket terjedelmi okok miatt most nem közöljük. A Books On- 
line-ban részletesen dokumentálva vannak mindannyian. 
Végül, de nem utolsó sorban beszéljünk az egyik leghaszno- 
sabb függvénycsaládról: a dátumkezelő függvényekről. Ezek 
megérnek a többinél kicsit több figyelmet. 


Dátumzsonglőrködés 

Eddig elég egyszerű volt bevetni a GROUP BY-t, mivel midig 
volt egy olyan oszlop, amire természetesen lehetett csoporto- 
sítani. Azonban ilyen nem mindig létezik. Például az előző 
példában az OrderDate napra kerekített érték volt, így könnyű 
volt napra csoportosítani, mivel csak be kellett írni a GROUP 
BY-ba. De mit teszünk, ha heti bontásban várják a kimenetet? 
Ha nem ismerjük a DATEPART függvényt, akkor bajban le- 
szünk. De ha igen, akkor: 


SELECT 
DATEPART(wk, OrderDate) AS WeekNum, 
"Amount" - SUM(od.UnitPrice § 


od.Ouantity) , 
COUNT(:r) AS OrderedProducts 
FROM 


WHERE 
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OrderDate BETWEEN 

"1998.01.01" AND "1998.02.01" 
GROUP BY 

DATEPART(wk, OrderDate) 
HAVING 

COUNT(r) 51 
ORDER BY 

WeekNum, Amount DESC 


WeekNum Amount OrderedProducts 
d 4691.0000 12 
2 30894.6600 30 
3 18822.6700 38 
4 24330.5400 38 
5 22115.8500 34 


A DATEPART függvény az egyik leggyakrabban használt beépí- 
tett függvény. Visszatér egy egész számmal, ami a date para- 
méterben megadott dátum egy bizonyos darabjának felel 
meg. A használata nagyon egyszerű: 


DATEPART(datepart, date) 
ahol a datepart a következő kifejezések valamelyike lehet: 


Jelentés Teljes név Rövidítés 


Év year 









7 Hónap month mm, m 





7 Nap day 








TOK hét n. napja 


weekday dw 






minute 





A függvényben használhatjuk mind a teljes nevet, mind a 
rövidítést. 

A példánk bizony sánta. Mivel minden évben van 1. hét, 2. hét, 
satöbbi, ezért a lekérdezésünk össze fogja vonni az összes év 
ugyanazon hetébe eső eladásokat. Ez természetesen nem he- 
lyes, és ezt a problémát úgy fogjuk orvosolni az utolsó, szinte 
tökéletes lekérdezésünkben, hogy a hét sorszáma mellé felso- 
roljuk az évet is mind a SELECT utáni listában, mind a GROUP 
BY-ban, így egyértelműen azonosítva lesz a hét. 

Az előző példánkban arra voltunk kíváncsiak, hogy az adott 
dátum az év hányadik hetébe esik. Azonban az SOL Servert 
Amerikában írták, ahol a hét első napja a vasárnap, nem pe- 
dig a hétfő. ők tudják, mi a jó nekik, azonban a DATEPART is 
ennek megfelelően működik, aminek mi nem örülünk. Mivel 
azonban a Microsoft nem csak Amerikában akarja eladni az 
SOL Servert, ezért beépítette annak lehetőségét, hogy meg- 
változtassuk a hét első napját: 
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SET DATEFIRST 1 


Ennek hatására a hét első napja ismét a hétfő lesz, így az 
összes dátumkezelő függvény helyesen fog működni. Az SOL 
Serverben sok, a fentihez hasonló beállítás létezik, amelyekkel 
a szerver alapértelmezett viselkedését változtathatjuk meg. 
Ezekkel egy későbbi cikkben még részletesen foglalkozunk. 

A dátumkezelő függvények további igen hasznos képviselője 
a DATEADD függvény. Ez, mint a neve is sugallja, arra való, 
hogy egy dátumhoz hozzáad valamilyen időintervallumot. Mi 
határoz meg egy időintervallumot? A hossza és a mértékegy- 
sége. Ennek megfelelően a függvény formátuma a következő: 
DATEADD (datepart , number, date) 

A datepart az előző táblázatban közölt értéket veheti fel, a 
weekday kivételével, mert annak nincs semmi értelme ebben 
az összefüggésben. Szerintem a dayofyear-nek sincs, de az 
úgy működik, mintha day-t írtunk volna. A number egy egész 
szám, ami az intervallumot írja le. A date pedig a kiinduló dá- 
tum. Nézzük meg működés közben: 


SELECT DATEADD(day, 1, "2000/01/05 18:12") 
2000-01-06 18:12:00.000 

SELECT DATEADD(mi, 5, "2000/01/05 18:12") 
2000-01-05 18:17:00.000 

SELECT DATEADD(hh, -3, "2000/01/05 18:12") 
2000-01-05 15:12:00.000 

DECLARE (d DATETIME 

SET €d - !"2000/01/05 18:12" 

SELECT €d 4 3 

2000-01-O8 18:12:00.000 


Az első három példa morális tanulsága: nincs DATESUB, a DA- 
TEADD-ot kell negatív számmal meghívni. 

Az utolsó példa ravasz. Egy dátum típusú mezőhöz hoz- 
záadunk 3-at, egy egész számot, aminek az a jelentése, hogy 
a dátumot megnöveli 3 nappal. Érdekes, de ha valaki nem 
tudja explicit a -- operátor e polimorf tulajdonságát, az meg- 
lepődhet a kódunkon. 

A harmadik hasznos dátumkezelő függvény a DATEDIFF. For- 
mátuma: 


DATEDIFF (datepart, startdate, enddate) 
Azaz a startdate és enddate dátumok különbségét adja vissza 


a datepart-ben definiált egységben: 


--Hány másodperc is egy nap? 


SELECT DATEDIFF ( second, "2000.01.01", 
"2000.01.02") 
86400 


Dátum agytorna 

Szép lett az előző példánk listája, de nekem például nem so- 
kat mond az, hogy most a 38. hétben járunk. A menzán és a 
hivatalokban gyakran láthatjuk ezt a fajta időmeghatározást, 
de nekem sokkal szimpatikusabb lenne a lista, ha a hetet jel- 
ző szám mellett ott láthatnám azt is, hogy mely dátumhatá- 
rok zárják az adott hetet. Próbáljuk meg kitalálni, hogyan le- 
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hetne ezt összerakni Transact SOL-ben. Nem lesz triviális, ké- 
retik egy dupla KV-t inni a következők előtt! 

Adott a dátumunk, tároljuk ezt a (2d változóban. Azt, hogy 
ez a dátum az év hányadik hetébe esik, a DATEPART(week, 
(2d) függvénnyel könnyedén megtudhatjuk. Hogyan lesz eb- 
ből meg a keresett hét kezdő dátuma? Úgy, hogy valahogyan 
meg kellene találni az adott év első hétfőjét, és ahhoz hozzá 
kellene adni annyiszor 7 napot, ahányadik héten járunk az el- 
ső hétfőhöz képest. Az év eleji tört hét is hétnek számít! Néz- 
zük meg mindezt Transact SOL-ben! 


--A hét első napja a hétfő legyen 

SET DATEFIRST 1 

--Ehhez a dátumhoz keressük a hetet és a 
-—-hetet záró határokat 

DECLARE éd DATETIME 

--Ebben lesz az év első napjának dátuma 
—-ea(nem első hétfő, hanem január elseje!) 
DECLARE EdFirstDayOfYear DATETIME 

—-eTeszt dátum. Ez egy keddi nap a 2. héten 
SET €d — "2000/01/04" 

--A dátumhoz tartozó hét tesztelése 

SELECT DATEPART(week, €d) 

2 

--Az év első napjának megkeresése 

SET GdFirstMondayOfYear - CONVERT(CHAR(4), 
112) 

SELECT EdFirstDpayOfYear 

2000-01-OL1 00:00:00.000 


ea, 


Itt álljunk meg egy pillanatra. Mi az a CONVERT függvény, és 
mit jelent a 112-es paraméter? A CONVERT a különböző adat- 
típusok közötti konverzióra való. Különösen akkor hasznos, 
ha dátum formátumot kell szöveggé konvertálni. Az első pa- 
ramétere mondja meg, hogy milyen típussá szeretnénk kon- 
vertálni. Itt char(4)-et adtunk meg, ami 4 karaktert képes tá- 
rolni. A második paraméter a konvertálandó kifejezés, a har- 
madik pedig a konvertált eredmény formátumát szabályozza. 
Dátum bemenet és szöveg kimenet esetén a 112 azt jelenti, 
hogy a dátumot yyyymmdd formátumra konvertálja át. De 
hisz az eredmény 8 karakter, mi meg char(4)-et adtunk meg! 
Ez benne a trükk. 2000. 01. 04.-ből 20000104 lenne, de mi- 
vel a char(4) csak az első 4 karaktert képes eltárolni, a mara- 
dék négy egyszerűen elveszik. Azaz mi lesz a konverzió ered- 
ménye? "2000". De akkor miért kaptunk a SELECT (OdFirstDa- 
yOfYear eredményeként  2000-01-01-et? Azért, mert a 
(oOdFirstpayOfYear dátum típusú, és a szerver a , 2000" sztrin- 
get 2000. január 1-é konvertálta. Implicit módon, azaz anél- 
kül, hogy erre külön megkértük volna. Ez azért egy kicsit pisz- 
kos munka volt. Inkább segítsünk neki: 


SET EdFirstDayOfYear -— 
12) 4 "0101" 
2000-01-O1 00:00:00.000 


CONVERT(CHAR(4), Ed, 


Na, ez így már szép. De menjünk tovább. Hogyan kapjuk meg 
ebből az első hétfőt? Ha tudjuk, hogy január elseje a hét há- 
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nyadik napja, akkor ebből már könnyű kiszámolni, hogy az el- 
ső hétfő hányadikára esik: menjünk vissza az év első napjától 
annyi napot, ahányadik napra esik az a hétben, és adjunk 
hozzá 8-at. Például 2000. január elseje szombat volt, ami a 
hét 6. napja. 





SELECT DATEPART(weekday, 
6 


edFirstDpayOofYear) 


Ha visszamegyünk 6 napot, az 1999. december 26-a, ami a 
2000. év első hétfőjét megelőző hétfő előtti nap (vasárnap). 


SELECT DATEADD (day, -DATEPART(weekday, 
edFirstDayOfYear), EdFirstDayOfYear) 
1999-12-26 00:00:00.000 


Ehhez már csak hozzá kell adni 8 napot, és meglesz a 2000. 
év első hétfője. 


SELECT DATEADD (day, -DATEPART(weekday, 
€dFirstDayOfYear)t8, EdFirstDpayOfYear) 
2000-01-03 00:00:00.000 


Eljutottunk a tárgy év első hétfőjéig. Most már nincs más dol- 
gunk, mint ehhez hozzáadni annyiszor 7 napot, ahányadik 
héthez keressük a hetet kezdő hétfőt. 


SELECT  DATEADD(day, (-DATEPART(weekday, 
e€dFirstDayOfYear)t8) t (DATEPART(week, ((d)- 
2)"7, edFirstpayOfYear) 


2000-01-03 00:00:00.000 


Azért kellett kettőt kivonni a hét számából, mert 1-től kezdődik a 
hetek számozása és nem 0-ától, valamint, mert az aktuális napot 
megelőző hétfőre vagyunk kíváncsiak, nem pedig a következőre. 
A záró napot innentől kezdve gyerekjáték meghatározni, csak 
nem kettőt, hanem egyet kell kivonni a hetek számából. 


SELECT  DATEADD(day, (-DATEPART (weekday , 
eGdFirstDayOfYear)t8) 4 (DATEPART(week, €d)- 
1)"7, €dFirstpayOfYear) 


2000-01-10 00:00:00.000 


Alakítsuk át a korábbi GROUP BY-os példánkat úgy, hogy a he- 
tek száma mellé legyen kiírva azok kezdete és vége is. Ehhez 
az előbb kiagyalt kifejezéseket össze kell vonni, és be kell ír- 
ni a megfelelő helyre a kiinduló lekérdezésben, valamint rak- 
juk bele az évet is, ahogy korábban ígértük: 


SET DATEFIRST 1 

SELECT 
DATEPART(year, OrderDate) AS YearNum, 
DATEPART(wk, OrderDate) AS WeekNum, 
DATEADD(day, (-DATEPART(weekday, 
CONVERT(CHAR(4), OrderDate, 112) 4 
".01.01")48) 4 (DATEPART(week, 
OrderDate)-2):r7, CONVERT(CHAR(4), 
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OrderDate, 112) 4 ".01.01") AS StartDay, 
DATEADD(day, (-DATEPART(weekday, 
CONVERT(CHAR(4), OrderDate, 112) t 
".01.01")48) 4 (DATEPART(week, 
OrderDate)-1) 7, CONVERT(CHAR(4), 
OrderDate, 112) 4 ".01.01") AS EndDay, 
"Amount" - SUM(od.UnitPrice § 
od.Ouantity) , 
COUNT(§r) AS OrderedProducts 

FROM 

WHERE 
OrderDate BETWEEN 
"1997.12.22" AND "1998.01.18" 

GROUP BY 
DATEPART(year, OrderDate), 
DATEPART(wk, OrderDate), 
DATEADD(day, (-DATEPART(weekday, 
CONVERT(CHAR(4), OrderDate, 112) t 
".01.01")48) 4 (DATEPART(week, 
OrderDate)-2) 17, CONVERT(CHAR(4), 
OrderDate, 112) t ".01.01"), 
DATEADD(day, (-DATEPART(weekday, 
CONVERT(CHAR(4), OrderDate, 112) 4 
".01.01")48) 4 (DATEPART(week, 
OrderDate)-1) 17, CONVERT(CHAR(4), 
OrderDate, 112) 4$ ".01.01") 

ORDER BY 
WeekNum, Amount DESC 


YN WN StartDpay EndDay Amount OP 
1997 52 1997-12-22 1997-12-29 17678 32 
1997 53 1997-12-29 1998-0O1-O5 14871 18! 
1998 1 1997-12-29 1998-0O1-O5 4691 12! 
1998 2 1998-01-O5 1998-01-12 30894 30 
1998 3 1998-01-12 1998-01-19 18822 38 


Konklúzió 

Látható, hogy az évváltásnál nem jól működik a dátumkezelő al- 
goritmusunk. Ezt még tökéletesíteni fogjuk a következő számban. 
És miért lett ennek az egyszerű feladatnak a megoldása ilyen 
bonyolult, annak ellenére, hogy nem is tökéletes? Azért, mert 
majdnem ugyanazt a hosszú kódrészletet négyszer egymás 
után le kellett írnunk, szinte változatlanul. De hát nem azt ta- 
nultuk az iskolában, hogy az ismétlődő kódrészeket függvé- 
nyekbe kell rakni? De! És nem arról regéltek nekünk, hogy a 
függvények paraméterezésével még a nem teljesen azonos 
kódrészeket is össze lehet vonni? De, de, de! Akkor miért nem 
élünk ezzel a lehetőséggel? Microsoft SOL Server 7-ig azért 
nem, mert nem volt meg a módunk erre, mert nem voltak User 
Defined Function-ök, felhasználói függvények. De SOL 2000- 
ben végre vannak, és pont az ilyen problémákra adnak igen 
elegáns megoldást. De erről majd a következő részben. 


Soczó Zsolt MCSE, MCSD, MCDBA 
Protomix Rt. 
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A kiszolgálók lesznek a számítástechnika új központjai? 


A személyi számítógépek gyorsan fejlődtek az elmúlt 
két évtized folyamán, és olyan számítási teljesít- 
ményt nyújtanak, melyet régen elképzelni sem 
tudtunk volna - ráadásul több százmillió em- 
bernek. Most, hogy a kommunikációs hálóza- 
tok is robbanásszerű fejlődésen mennek át, so- 
kunk kíváncsi rá, hogy vajon ismét központo- 
sítva lesz-e a számítástechnika világa. 

Óhatatlanul felmerül bennünk a kérdés: nem le- 
hetséges-e az, hogy egy ,izmos" asztali gép, laptop 
vagy akár PDA (Personal Digital Assistant) helyett ezeknél 
sokkal egyszerűbb eszközöket használjunk, melyek nagy- 
sebességű hálózati kapcsolatokon keresztül érnek el hatal- 

mas teljesítményű központi számítógépeket? 
Ez igen csábító elgondolás. Az információk központilag táro- 
lódnak, és bárhonnan elérhetjük őket. Ha a zene, melynek meg- 
hallgatási jogát megvásároltuk központilag lenne tárolva, nem 
lenne szükséges otthonunkban CD lemezeket vagy audio kazet- 
tákat (vagy bármely más hanghordozót) tartani, bár a Hi-Fi mi- 
nőség eléréséhez még mindig ra- 

gaszkodnunk kellene ezekhez. 

Való igaz, néhány tárolóeszköz 
központi helyre kerül. Az elektro- 
nikus levelezést szolgáló progra- 
mok például vagy az asztali gép 
merevlemezén, vagy a központi 
vállalati kiszolgálón (esetleg 
mindkettőn) tárolják az üzenete- 
ket. A Hotmail.com elképesztő 
népszerűsége - mely annak köszönhető, hogy felhasználói bár- 
mikor, bárhonnan elérhetik ezt az ingyenes e-mail alkalmazást, 
melynek csak központi tárolója van - bizonyítja legjobban a 
központilag tárolt információ szükségességét. A Hotmail-nek 

ugyanis több mint 25 millió felhasználója van. 
Az információ kétségkívül egyre központosítottabbá válik, a ki- 
szolgálók pedig egyre nagyobb teljesítményűek lesznek. Ezek a 
kiszolgálók biztosítják a webhelyek elérhetőségét, összevonják 
az adatokat, és kereshetővé teszik azokat. A nagy központi szá- 
mítógépek egyre több adatunkat fogják tárolni, és automatiku- 
san elérhetővé teszik azokat számunkra, függetlenül attól, 
hogy mi, a végfelhasználók milyen számítógépet is használunk. 
De ez semmiképp sem jelenti azt, hogy a PC-k és más infor- 
máció-elérést szolgáló eszközök, melyekkel az emberek a ki- 
szolgálókhoz kapcsolódhatnak, kevésbé intelligensek lesz- 
nek. Épp ellenkezőleg, ezek teljesítménye is növekedni fog. 
Az elmúlt években kiegyensúlyozatlanság volt megfigyelhető. A 
számítási teljesítmény és a tárolókapacitás legnagyobb növekedé- 
se a PC-knél jelent meg, melyeket az emberek közvetlenül hasz- 
nálnak, és amelyeket ezért általában , ügyfeleknek" hívunk. Ter- 
mészetesen a kiszolgálók is fejlődtek, de nem igazán tartottak 
lépést a kapcsolat ügyféloldalán végbemenő gyors fejlődéssel. 
Az elkövetkezendő években a kiszolgálók képességei várhatóan 
gyorsabban fognak fejlődni, mint az ügyfeleké. A teljesítmény mind- 
két oldalon nőni fog, ám most a kiszolgálók javára billen a mérleg. 
Az egyik oka annak, hogy a kiszolgálók önmagukban nem 
képesek kielégíteni az összes jövőbeni igényt, az, hogy a 
kommunikációs infrastruktúra még nem elég jó, és egy jó 





darabig még nem is lesz az. 
Az irodákban dolgozók általában meglehetősen gyors hálóza- 
tokat használnak, de a legtöbb Internetre kapcsolódó ottho- 
ni felhasználó betárcsázásos, telefonos hálózatot használ. A 
kábelmodemek és a telefonos DSL kapcsolatok néhány helyen 
megvalósulnak, de a nagysebességű otthoni kapcsolatok a 
legtöbb ember számára még sokáig elérhetetlenek maradnak, 
még az Egyesült Államokban is. Az USA-ban sok PC nem kap- 
csolódik az Internetre, és ez az arány Európában még rosz- 
szabb, mert itt sokkal magasabbak a kommunikációs költsé- 
gek (az USA-ban a helyi hívások ingyenesek - a ford.) . 
Ráadásul még a kábelmodemek és a DSL kapcsolatok sem elég 
gyorsak ahhoz, hogy például a hagyományos televíziónak 
megfelelő minőségű képátvitelt biztosítsanak. Egy igazán jó 
Internet-kapcsolatnak 1 megabitet kellene átvinnie másod- 
percenként - manapság egy CD-ROM ennél 50-szer, egy me- 
revlemez pedig százszor nagyobb teljesítményre képes. 

Mivel időbe telik, amíg az adatok átmennek a hálózaton, fon- 
tos az ügyfél és a kiszolgáló között átviendő adatmennyisé- 
get minimálisra csökkenteni. Ennek pedig egyik (és legkézen- 
fekvőbb) módja az, hogy bőséges számítási teljesítményt, me- 
móriát és tárolókapacitást biztosítunk ügyféloldalon, így nem 
kell szükségtelenül a kiszolgáló erőforrásaira támaszkodnunk. 
Az ár/teljesítmény viszonyszám gyors csökkenésével egyre in- 
kább lehetséges ennek megvalósítása. Az alacsony árak miatt 
az emberek , kezébe adhatjuk" ezt a teljesítményt, és ha az 
ügyfélgépek teljesítménye elegendő, csak kevés idő vész el a 
kiszolgáló és az ügyfél között zajló adatkommunikáció miatt. 
Mindegy, hogy egy hálózati kapcsolatnak mekkora a sávszé- 
lessége, mindenképpen lesznek lassulások a ,késleltetés" 
miatt. Az egyik ilyen lassulást okozó tényező a fény sebessé- 
ge, amely határt szab az információáramlás gyorsaságának. 
Egy másik ok arra, hogy a számítási teljesítmény miért nem 
lesz központosítva az, hogy ebből rengetegre van szükség az 
új eszközök, adattípusok és a multimédiás folyamatos adat- 
átvitel (például videolejátszás) kezeléséhez. Szükség van a 
számítási teljesítményre az új számítógépes játékoknál is, 
melyek háromdimenziós, gyorsan mozgó alakzatokat jeleni- 
tenek meg. Egy központi kiszolgálóhoz kapcsolt terminál pe- 
dig erre egész egyszerűen nem képes. 

Az embereknek olyan eszközökre lesz szükségük, mely alkalmaz- 
kodik minden olyan új dologhoz, amit csak hozzá akarnak kap- 
csolni. Ezeknek a perifériáknak a számbeli növekedése még so- 
káig folytatódni fog, a számítási teljesítmény pedig eloszlik. 
Végül, bár úgy tűnik, hogy az információ központilag tároló- 
dik, jelentős része helyben is megtalálható. Ily módon akkor is 
elérhetjük információinkat, ha éppen nincs hálózati kapcsola- 
tunk, a kiszolgáló nem működik, vagy a hálózat leterheltsége 
miatt csak lassan, vagy egyáltalán nem tudnánk azt elérni. Az 
adatok tükrözése az összes olyan eszközre, melynek el kell azo- 
kat érnie, a két , világ" jó tulajdonságait egyesíti. Ha az ügy- 
félgép véletlenül meghibásodna, az információk egy központi 
helyen el vannak mentve, egyébként pedig gyorsan, helyben 
elérhetők. Az adatok a felhasználók számára észrevétlenül má- 
solódnak át a különböző gépekre, így maradnak szinkronban. 
A tárolókapacitás tehát központosul? Általában igen. A szá- 
mítási teljesítmény viszont nem. 








Dupla pezsgő 


K: Kezdeti sikerek után rendre 
elakadok a Minesweeperrel végzett 
munkámban. Noha a Beginner ál- 
talában sikerül, az Expert szinte 
soha, mert a legutolsó néhány bomba sajnos nem egyértel- 
műen rejtőzik a mezők alatt. Ilyenkor becsukott szemmel, 
imát mormolva kattintok egyet, de ez a módszer gyakran 
nem jön be. Csalódott és kielégítetlen vagyok. 





V: Bizony sokan nehezen jutnak túl az informatikussá vá- 
lás eme nehéz fázisán. Valóban az a legbosszantóbb eset, 
amikor már csak négy mező van hátra az Expert kirakásá- 
hoz, mint az alábbi ábra esetében: 


AE 
Game Help 
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Ha kiemeljük a problémás részt, rövid gondolkodás után rájö- 
hetünk, hogy itt patthelyzet alakult ki. 
Két akna van hátra, ám azok egyfor- 
ma eséllyel helyezkedhetnek el a bal 
alsórjobb felső átlón, valamint a 
jobb alsó--bal felső vonalban. Ennyi- 
re kényes helyzetekben csak a NetAcademia, mint kiemelt 
megoldásszállító segíthet! Ha valami nem megy, az csak 
átmeneti állapot lehet, esetleg saját tudatlanságunk mo- 
csarában vergődünk, mint jelen esetben is. A NetAcademia 
rendszermérnökei a legkorszerűbb módszerek igénybevéte- 
lével (Internet böngészése stb.) jutnak hozzá létfontosságú 
információkhoz, amelyeket azután rendszeresen megoszta- 
nak a magyar IT társadalommal. Sajnos Redmond egyelőre 
nem ismeri el erőfeszítéseinket, pedig a Winmine-probléma 
megoldása fontosságban vetekszik holmi primitív kék halá- 
lok elhárítási trükkjeivel; szerintünk e tudásnak egyértel- 
műen a Knowledge Base adatbázisban a helye! 

A megoldás egyébként rém egyszerű. Szorult helyzetünkben 
gépeljük a Minesweeper arcába a következő karaktersorozatot: 





XYZZYCEnter:CBal Shift: 
(Természetesen a kacsacsőrök nélkül!) 





DUPLA KVIFPEZSGŐ 


E billentyűkombináció ismerete sokkal fontosabb, mint 
a Ctrl4Alt--Del-tudás, hisz ez magát a mission criti- 
cal Winmine.exe-t kapcsolja át debug üzemmód- 
ba! Ezután a képernyő bal felső 
sarkában lévő képpont (magyarul 

k € pixel) kigyullad, és annak megfe- 
lelően villog, hogy az egérkurzorral vajon akna fe- 
lett járuk-e. Ha igen, elfeketedik! :-0O 
Így már gyerekjáték a fenti feladványt megfejteni: 
A hála, kegyelet és megemlékezés csokrait a szer- 
kesztőségbe kérjük... 





Troubleshooting 

Sajnos hiba nélkül nincs haladás, a Winmine-paradoxon 

sem fog mindenki számára azonnal megoldódni. Ha a pixel 

nem gyullad ki, annak két oka lehet 

1. Elgépelődött a varázsbillentyűkód. Try again. 

2. A bal felső pixel kilóg a képernyőről. Megoldhatatlan 
probléma, ilyenkor feltétlenül forduljunk szakember- 
hez. (Például megkérhetjük a takarítónénit, hogy ismé- 
telje meg azt a techno-portörlést, amitől kiment a kép a 
monitor káváján kívülre, s közben próbáljuk meg ellesni, 
és feljegyezni, hogyan csinálja!) 


BUÉK! 
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1994-ben ismerkedtem meg a Microsoft SOL 
Server-rel, 4.0 a volt a verziószáma. Mai 
szemmel nézve persze döbbenetesen primitív 
volt, ám már akkor is rendelkezett azokkal a 
képességekkel, amelyek miatt az ember öröm- 
mel dobta el a Clipper-t: tranzakciókezelés, 
ügyfél-kiszolgáló felépítés, többszálú végre- 
hajtás stb. Félelmetesen összetett banki 
rendszereket készítettünk akkoriban 486DX4- 
100 processzoros, 16 megabájt memóriával felvértezett , szervereken". 
Az elmúlt évek során az SOL Server megfiatalodott: fürge lett és erős. S 
ahogy verzióról verzióra fiatalodott, úgy vált egyre okosabbá is. Zseni- 
ális lekérdezés optimalizálója segítségével szakavatott kezekben szár- 
nyakat kap. A TPC-C teljesítménytesztek világbajnoka rendszerfelü- 
gyeleti szempontból is kiváló termék. A 7.0 már lehetővé tette az adat- 
bázis által összegyűjtött adatok okos elemzését, hisz megjelent benne 
az OLAP kiszolgáló. S ami napjainkban lázba hoz, az a mesterséges in- 
telligencia határmezsgyéjén található adatbányászat. Az adatok rejtett 
összefüggéseinek feltárása minden adatbázis tartalmát életre kelti. 
Januárban a NetAcademia Kft, a BST Kft. és a Microsoft Magyarország 
közös szervezésében megrendezésre kerülő 


SOL Server Napon 


megpróbálok valamennyit átadni azokból a tapasztalatokból, melyek 
az évek során ,rám rakódtak". Természetesen egyetlen nap nem lehet 
elegendő a teljes információhalmaz átadására. Mindenkit szeretettel 
várok SOL Server 2000 tanfolyamaimon, melynek helyszíne a Business 
Software Training Hivatalos Microsoft Oktatóközpont (CTEC). 








T a ARC Business . 
§ !! Software 
"Training 


Jelentkezés a konferenciára és 
részletes tudnivalók a 
http://www.netacademia.net/SOLna; 
vagy 
http://www.bst.hi Lnaj 
címen! 


Az SOL Server nap rövid tematikája a következő: 


s Adatbázisok a rendszergazda hozzáértő kezében. 
Azaz mi mindent tehetünk a teljesítmény fokozása 
érdekében még akkor is, ha készen vett alkalma- 
zással van dolgunk? 


s Az SOL 2000 újdonságai programozók számára. 
Ismerkedjünk meg az SOL 2000 fejlesztőknek szóló 
fantasztikus újdonságaival: XML támogatás, fel- 
használói függvények, indexelhető nézetek, inste- 
ad-of triggerek, Kaszkád referenciális integritás 


e Adatbányászat A mesterséges intelligencia 
határmezsgyéjén húzódó technológia az adatok kö- 
zött megbúvó rejtett összefüggések feltárására. 


s Online Analitical Processing. Adatelemzés 
mesterfokon 
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